| Author |
Message |
|
|
 Posted: Apr 19, 2012 - 04:11 PM |
|
Joined: Apr 07, 2011
Posts: 33
Location: Utah, USA
|
|
Hi everyone, I've lately been dabbling with a few of the more higher power microcontroller families and I was wondering what your opinions were about ARM vs Renesas.
If you have any opinions/pointers to what family would be the most beneficial to focus on, feel free to share.
Thanks! |
|
|
| |
|
|
|
|
|
|
Posted: Apr 19, 2012 - 05:04 PM |
|
Joined: Sep 12, 2009
Posts: 2471
Location: Sacramento, CA
|
|
Everybody makes ARM devices, so you'll have an enormous selection, starting from not much more than $1. And everybody makes ARM tools. And everybody makes ARM boards to play with. And everybody has ARM forums.
Seems like ARM is the dabbler's delight. You can get an STM32VLDiscovery board for about $9. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 19, 2012 - 06:58 PM |
|
Joined: Jul 21, 2005
Posts: 1377
|
|
Never touched Renasas, I have experience with ARM and it is pretty smooth depending on the documentation and app notes from each particular vendor.
But both are just a platform like any other, so why not just learn both? |
|
|
| |
|
|
|
|
|
|
Posted: Apr 19, 2012 - 07:34 PM |
|
Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
I've just started to get into Atmel's ARMs through testing Atmel Studio 6 internally, and I quite like it - haven't tried Renesas. So far I've discovered after comparing this to my last ARM attempt that the tools, development environment and chip peripheral design makes up 99% of the experience, and the actual core design used to shift the bits around doesn't really matter.
On that note, while everyone makes ARM core devices, remember that everyone also has different peripheral designs - so unless you are using something simple like a USART, your code isn't really "recompile and run" portable anyway if you swap vendors.
- Dean  |
_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
|
Posted: Apr 19, 2012 - 07:56 PM |
|
Joined: Nov 17, 2004
Posts: 6144
Location: Great Smokey Mountains.
|
|
The title and OP makes no sense since Renesas makes an ARM based product.
So my 'honest opinion' is that you should be looking for various Renesas competitors like Atmel who also make ARMs and try to compare their ARM implementations.
Smiley |
_________________
FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com
|
| |
|
|
|
|
|
|
Posted: Apr 19, 2012 - 08:00 PM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
So far I've discovered after comparing this to my last ARM attempt that the tools, development environment and chip peripheral design makes up 99% of the experience, and the actual core design used to shift the bits around doesn't really matter.
And this for money is where ARM really scores for those who've been using avr-gcc and want to "trade up". Same compiler, same linker, same debug format, same options, same binutils.
I came the other way - deeply steeped in the lore of arm-gcc (actually patr of a Linux ARM development) and loved the fact that this tiddly little 8 bit micro had the same "grown ups" compiler and toolchain available for it. It's just a shame that the debug side of things (gdb, avarice, simulavr) are not as advanced as they are in the arm-gcc world. (well OK gdb is but it's avarice that is the block to being able to use exactly the same tools as you do for arm-gcc development).
As for Renasas. Who?
(OK I know who but you get the point?) |
_________________
|
| |
|
|
|
|
|
|
Posted: Apr 19, 2012 - 09:33 PM |
|
Joined: Nov 22, 2002
Posts: 12193
Location: Tangent, OR, USA
|
|
Maybe a "better" question would be AVR32 vs ARM???????
Jim |
_________________
Jim Wagner
Oregon Research Electronics, Consulting Div.
Tangent, OR, USA
"The only thing standing between us and victory is defeat" P.G.Wodhouse in Wooster & Jeeves series
|
| |
|
|
|
|
|
|
Posted: Apr 19, 2012 - 09:43 PM |
|
Joined: Oct 04, 2008
Posts: 413
|
|
I (being a hobbyist) have tried to get an insight what I can do with ARM timers from NXP, ST and Atmel. May be they are "all the same" but Atmel's explanation and documentation was by far the easiest to understand for me. I really like their documentation!
Compare this: http://www.atmel.com/Images/11100.pdf
with what the others offer... |
|
|
| |
|
|
|
|
|
|
Posted: Apr 19, 2012 - 09:51 PM |
|
Joined: Sep 12, 2009
Posts: 2471
Location: Sacramento, CA
|
|
|
gdhospers wrote:
I (being a hobbyist) have tried to get an insight what I can do with ARM timers from NXP, ST and Atmel. May be they are "all the same" but Atmel's explanation and documentation was by far the easiest to understand for me. I really like their documentation!
Compare this: http://www.atmel.com/Images/11100.pdf
with what the others offer...
Wow, still only fixed prescales on their timers? Am I reading that right? Atmel, what were you thinking?! |
|
|
| |
|
|
|
|
|
|
Posted: Apr 20, 2012 - 12:16 AM |
|
Joined: Dec 30, 2004
Posts: 8998
Location: Melbourne,Australia
|
|
No lack of flexibility on the STM32 timers, but the more options you have, the harder it is to figure out. My first attempt at getting a STM32 timer to work similar to an AVR took a bit longer than expected and needed a work around. Not sure if it was just me of the avtual hardware. One day I'll post the question on the ST forums. NXP timers seem to work as expected.
As for the OP's question, the eval boards are dirt cheap these days so to try both is not unreasonable. The deciding factor for me is the cost/features of the tools. For a hobbyist, the free tools are probably the deciding factor. For me, NXP is the winner at the moment.
As for Atmel's offerings, i did a SAM7 project a few years ago that was rather torturous as i used a cobbled together mix of eclipse and gcc. Things like startup files took a while to get working. The prepackaged solutions like Rowley and CodeRed are much nicer. As for ST, the Attolic offering is now code limited to 32k which is next to useless. No comment on Studio6 as i've not ventured down the SAM3 path nor on the Renesas tools. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 20, 2012 - 12:46 AM |
|
Joined: Jun 15, 2009
Posts: 134
Location: Northern California
|
|
|
ka7ehk wrote:
Maybe a "better" question would be AVR32 vs ARM???????
I'm a big fan of the AVR32 and the ARM, so I'll comment here.
First, a couple of observations on the original post in this thread. What do you mean by "higher power"? Compared to what? An MSP430, for example? Secondly, I assume you realize that the ARM family ranges from the Cortex-M0 on the low end up to the big A9 on the high end. That's quite a range.
In my opinion, the ARM Cortex-M3 and the AVR32 UC3 are more alike than different. They offer roughly the same performance and similar peripherals. The CPU architectures are very similar too, and if you're programming primarily in C, you won't even notice the differences.
The big difference is in vendor support. The AVR32 is Atmel, and only Atmel. If Atmel drops the AVR32, it's done for. ARM, on the other hand, is NXP, and STMicro, and TI, and Freescale, etc, etc. Heck, even Atmel does ARM.
ARM has a much wider range of tools available for it. With the AVR32 you're pretty much stuck with the Atmel tools. With ARM you have many more choices.
If I had to bet on which of these two architectures will still be available five years from now, all my money would be on ARM. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 20, 2012 - 05:39 AM |
|
Joined: Dec 26, 2006
Posts: 1407
Location: Sydney, Australia
|
|
| hhm... i have been wondering lately if I should invest my time with atmel ARM chips instead of the UC3... hhm.... |
|
|
| |
|
|
|
|
|
|
Posted: Apr 20, 2012 - 10:17 AM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
up to the big A9 on the high end.
This suggests A-15 in fact:
BTW to OP which ARm and which Renasas were you considering? I assume from Renasas in 32bit you are talking about the old NEC SuperH? Or did you mean the V850? About 12 years ago I remember when I went to Microsoft in Seattle to see the new "Windows CE" and the only option then was to run it on an NEC processor which I think was the forerunner of the V850 (would it have been V405?). Needless to say Microsoft did not get very far in the embedded world with "CE" when they wanted to charge $50 (like Windows) per unit for the operating system when the likes of VxWorks was <$1 per unit! |
_________________
|
| |
|
|
|
|
|
|
Posted: Apr 20, 2012 - 06:21 PM |
|
Joined: Jun 15, 2009
Posts: 134
Location: Northern California
|
|
|
luvocean1 wrote:
hhm... i have been wondering lately if I should invest my time with atmel ARM chips instead of the UC3... hhm....
The UC3/Atmel Studio 6/AVR ONE! combination is growing on me. I really like this environment, and would like it much better except for the following:
Compiler bugs (found a number of them, but I'm porting an RTOS to the UC3, and that really pushes a compiler...) and the poor Atmel documentation.
Regarding the documentation, it leaves a lot to be desired as the user guides leave many things up to interpretation when they should be specified completely and accurately. When I'm writing a device driver for a peripheral, I don't want to scratch my head wondering exactly how this bit in that register works, etc. It should be rigorously specified, not wishy-washy. Many things are missing too. Case in point: try to find anything describing the C calling convention in the Atmel documentation. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 20, 2012 - 07:03 PM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
except for the following:
Which then sounds like pretty much everything! What if anything makes UC3 development better than ARM development?
I guess the acid test of AS6 is to use arm-gcc which is a much more mature compiler than avr32-gcc or avr-gcc. |
_________________
|
| |
|
|
|
|
|
|
Posted: Apr 20, 2012 - 07:53 PM |
|
Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
|
Quote:
Regarding the documentation, it leaves a lot to be desired as the user guides leave many things up to interpretation when they should be specified completely and accurately. When I'm writing a device driver for a peripheral, I don't want to scratch my head wondering exactly how this bit in that register works, etc. It should be rigorously specified, not wishy-washy. Many things are missing too. Case in point: try to find anything describing the C calling convention in the Atmel documentation.
Would you be able to write up your thoughts on this and PM/email them to me, if you have the time? I'm sure the training team would love some directional feedback on how to improve, and I can direct the rest to the relevant teams (hardware and software).
- Dean |
_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 01:13 AM |
|
Joined: Jun 19, 2002
Posts: 983
Location: SF Bay area
|
|
"Renesas" is a big company with several different CPU architectures and a hell of a lot of chips ranging from 8-bit enhanced Z80s (or smaller) to linux-capable 32bit chips. "ARM" is family of several related 32bit architectures implemented by a wide variety of vendors, also spanning a wide range of performance.
"ARM or Renesas" is not a very meaningful question...
One thing to think about is that while ARM might seem to offer multiple sources, each vendor gets to include their own peripheral mix on the chips. If your application ends up relying on peripheral features, you probably end up just as single-sourced with an ARM as you would with a Renesas. Or a UC3... |
|
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 02:42 AM |
|
Joined: Jun 15, 2009
Posts: 134
Location: Northern California
|
|
|
clawson wrote:
Quote:
except for the following:
Which then sounds like pretty much everything! What if anything makes UC3 development better than ARM development?
It's not necessarily better, just different. The AVR32 has that exotic feel to it that the ubiquitous ARM doesn't. And like most Americans, I like to root for the underdog. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 05:48 AM |
|
Joined: Dec 18, 2001
Posts: 4779
|
|
If professional... consider which is more valuable on the resume'.
(ARM) |
|
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 06:13 AM |
|
Joined: Jun 15, 2009
Posts: 134
Location: Northern California
|
|
|
stevech wrote:
If professional... consider which is more valuable on the resume'.
(ARM)
Absolutely. No disagreement there.
I do this as a hobby (after doing it professionally for >20 years), so I can afford to play around with a little bit of everything, including oddballs like the AVR32. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 06:05 PM |
|
Joined: Mar 24, 2006
Posts: 191
Location: Canada
|
|
We use ARM and Renesas and, like MIPS, Renesas is not in the limelight as much.
The Renesas parts we use are very nicely integrated, one good example is how nicely the timers can be set to trigger each other making for some very fancy trigerring and it saved us quite a few board mods. Depending on which vendor supplies your ARM, you get the impression that ARM parts are a CPU plonked amongst the peripherals and good luck getting them to do what you want. The exageration is unfair with recent ARM parts but "the core doth not maketh the part"
Another example was the hassle we had with ARM of reading bytes on uneven boundaries. Yes, if you know about it it is easy enough but it's the type of gotcha that we didn't find with Renesas (the original part was the very popular Mitsubishi M16C).
Of course Renesas is now the combined Mitsubishi, NEC and Hitachi.
Remember the SHI-4 parts, I learned a lot about GCC from a SH1 dev board in the late 1990's. My first lesson was not to use printf() because of it used most of the flash - I nearly gave up thinking that GCC may be free but if you can't output information it's not going to help me much.
We often do micro comparisons for various subsystems, Renesas alsway does really well for our criteria where low power is important. Soft issues like the integration of peripherals is not to be ignored because it can lead to long delays and bugs. Documentation is good too. Our software groups don't seem to need much handholding to get the system going.
In this age where source code in C is relatively easy to port from one device to another the reason to use a part moves to other factors. We use IAR compilers and a suite of different code inspection, design and maintenance tools so it may be best to consider those aspects more thans which part you're going to use.
What about Linux, there is a massive base to use if you can get Linux running on your part. Can you use it, do you need it and can you get it running on Renesas?
What about using a DSP as a microcontroller, the core is DSP but so what, you programme it in C anyway.
I suggest you re-read westfw's comment, it has some key points.
Klave |
|
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 07:16 PM |
|
Joined: Nov 17, 2004
Posts: 6144
Location: Great Smokey Mountains.
|
|
|
Klave wrote:
We use ARM and Renesas and, like MIPS, Renesas is not in the limelight as much.
I don't understand why folks keep saying things like this. ARM is a system of processor cores manufactured by everybody and their brother. Renesas is a company that among other things manufactures ARM processors. They also manufacture other processors. Comparing ARM to Renasas as if both were processors is nonsense. If you want to compare the company that designs the ARM cores to the company that is Renesas that has some validity, as would comparing a specific implementation of and ARM device to a specific competing device manufactured by Renesas. But you guys keep referring to them both as processors. One is and one isn't. |
_________________
FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 10:25 PM |
|
Joined: Dec 18, 2001
Posts: 4779
|
|
A useful discussion would be the relative merits of the peripheral add-on I/O for each manufacturer's ARM core based products. There are dozens of ARM licensees, including Atmel. Each has their place in the market-share pecking order and that implies good marketing/support, low errata, and good value-add to the core.
But such a discussion wouldn't make sense on this venue. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 22, 2012 - 11:51 AM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
including Atmel
Talking of which - a comparison of M3 and UC3 chips shows that the peripherals are pretty close to identical. I think both ARM and AVR32 are designed in Atmel's French offices so it's maybe no surprise that they'd be so similar. As such the core itself probably matters little but I guess by going with ARM you have access to far more mature development tools. |
_________________
|
| |
|
|
|
|
|
|
Posted: Apr 22, 2012 - 11:57 AM |
|
Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
|
Quote:
Talking of which - a comparison of M3 and UC3 chips shows that the peripherals are pretty close to identical. I think both ARM and AVR32 are designed in Atmel's French offices so it's maybe no surprise that they'd be so similar.
Yup, IIRC they were specifically designed to use the same peripherals, unfortunately.
- Dean |
_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
|
Posted: Apr 22, 2012 - 12:10 PM |
|
Joined: Dec 30, 2004
Posts: 8998
Location: Melbourne,Australia
|
|
| The SAM7 was out of France as well. Great peripherals but the doc left a bit to be desired. Took a bit of fiddling to understand the trickier features of the timers and usarts. One of the unsung benefits of that series of chips was the small sector size flash. Used to good effect in the lego mindstorms controller when using lejos. Also the website AT91 was nowhere near as active or useful as AVRFreaks. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 22, 2012 - 06:37 PM |
|
Joined: Dec 18, 2001
Posts: 4779
|
|
| I sorely wish there were an ARM equivalent to AVRfreaks.net. Haven't found such. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 22, 2012 - 06:47 PM |
|
Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
|
Quote:
I sorely wish there were an ARM equivalent to AVRfreaks.net. Haven't found such.
It's at www.at91.com.
- Dean |
_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
|
Posted: Apr 22, 2012 - 07:49 PM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
Steve asked for an equivalent of Freak's 
(the above might as well be a deserted town in the dust bowl with tumbleweed blowing down mainstreet) |
_________________
|
| |
|
|
|
|
|
|
Posted: Apr 22, 2012 - 10:53 PM |
|
Joined: Jun 15, 2009
Posts: 134
Location: Northern California
|
|
|
abcminiuser wrote:
Quote:
Talking of which - a comparison of M3 and UC3 chips shows that the peripherals are pretty close to identical. I think both ARM and AVR32 are designed in Atmel's French offices so it's maybe no surprise that they'd be so similar.
Yup, IIRC they were specifically designed to use the same peripherals, unfortunately.
I don't consider the AVR32 peripherals to be particularly good at all. The UARTs are a good example: no FIFOs. If you want to receive data at 115200 baud, for example, you need to service an interrupt for every character.
The RTC is another example. This thing is extremely simplistic. Other MCUs have full-blown real-time clocks, rather than just a simple counter like the one in the UC3. Plus it doesn't have any way to maintain the count if main power is lost to the MCU. Other MCUs, like the LPC1768, for example, have RTCs that keep track of hours, minutes, seconds, and have provision to connect a 3v battery to maintain time across power failures.
The WDT is another example of an overly simplistic peripheral. The CLR register can be written with any value to reset the timer and prevent a timeout. This means that if the processor goes off into the weeds and starts executing random code, it's still possible for the watchdog to be accidentally reset enough to prevent a processor reset. Other MCUs have windowed watchdog timers, or at least require a special sequence to reload the timer to prevent accidental resets.
There are probably other deficiencies like this, but I haven't gotten around to looking at the other peripherals yet. |
Last edited by SalAmmoniac on Apr 23, 2012 - 03:54 PM; edited 1 time in total
|
| |
|
|
|
|
|
|
Posted: Apr 23, 2012 - 11:45 AM |
|
Joined: Aug 29, 2002
Posts: 790
Location: Muenster, Germany
|
|
I also did some parallel playing with ARM micros and Renesas (read: non-ARM) chips. Besides the many technical features all those architectures do offer, i found one main almost blocking factor against the use of Renesas chips: their documentation. What they do offer to the developer is quite amazing: on one hand you do get 10s of thousands of pages in hundreds of documents for any given architecture (almost too much to digest), on the other hand, if you're really after exact and unambiguous bit definitions or behavioural descriptions, you quickly find yourself fighting with the result of a disastrous asian->english translation. For me this is the main reason hesitating to seriously start work with Renesas products.
At the Embedded World i asked them why they did create new processor architectures like the RL78 and the V850, where the holy grail these days obviously seems to be anything around an ARM-core. They replied with: "Because we believe we can do better!"... |
_________________
Einstein was right: "Two things are unlimited: the universe and the human stupidity. But i'm not quite sure about the former..."
|
| |
|
|
|
|
|
|
Posted: Apr 23, 2012 - 04:06 PM |
|
Joined: Jun 15, 2009
Posts: 134
Location: Northern California
|
|
|
DO1THL wrote:
... if you're really after exact and unambiguous bit definitions or behavioural descriptions, you quickly find yourself fighting with the result of a disastrous asian->english translation.
This is a major problem. I spent all day Saturday writing a driver for the LCD on the EVK-1100--a job that should have taken maybe 1-2 hours--because the LCD is made by Samsung and whoever wrote the documentation obviously has problems with English. I had to make a lot of guesses and a lot of trial and error before I finally got things working.
I'm at the point now where I won't use a product unless it has documentation written in a professional manner.
Quote:
At the Embedded World i asked them why they did create new processor architectures like the RL78 and the V850, where the holy grail these days obviously seems to be anything around an ARM-core. They replied with: "Because we believe we can do better!"...
I see this as a good thing. Competition is always good, otherwise things stagnate and don't move forward. Where would we be today if AMD didn't think they could do it better than Intel? |
|
|
| |
|
|
|
|
|
|
Posted: Apr 28, 2012 - 04:24 AM |
|
Joined: Feb 19, 2010
Posts: 509
Location: Montreal, QC, CA
|
|
My personal opinion in the ARM world is NXP is the benevolent king. Top notch detailed and organized documentation, excellent thought to detail, for example the physical pin layout on chip (compared to ST or TI it's heavenly). I have only looked at the Atmel offerings when they just started the SAM family a couple of years back, and I was not impressed... Features were clearly lacking compared to competition and documentation although not extremely bad was not the best I ever read. The only reason I would go TI would be for an industrial or automotive set of features. They are big on timers, PWMs, and CAN but most don't have the cool features you want. That said I have not looked in detail at their lineup since their acquisition of Luminary Micro.
Philips/NXP just are great chips to work with.
I also agree, when shopping for ARM, you shop first for a tailored set of features, and second a desired clock rate. The codenames of the Cortex series don't mean much just use a parametric table somewhere. Then check out the documentations from different vendors and pick the one company that obviously went a little further than the others. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 29, 2012 - 08:46 PM |
|
Joined: Aug 29, 2008
Posts: 49
|
|
I agree with your comments on NXP documentation. It's first rate. It's what other chip companies should look at and strive to make their own documentation as good as or better.
I really like the AVR32 chips, but I'm having second thoughts about them primarily because the documentation is so bad. I can deal with simplistic peripherals, but having to guess how they work because all the details are not explicitly spelled out in the documentation is just not professional. Ruddy bad show, Atmel. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 30, 2012 - 12:49 AM |
|
Joined: Dec 18, 2001
Posts: 4779
|
|
How does NXP's documentation (e.g., user manual for LPC chips) compare to ST's ARMs? Atmels?
I too am impressed with NXP's docs, for the ARM7's anyway. But haven't worked much with anyone's Cortex chip/modules, though I have some like mbed and have only played with C++ on them. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 30, 2012 - 04:23 PM |
|
Joined: Jun 15, 2009
Posts: 134
Location: Northern California
|
|
In my opinion, ST's documentation is better than Atmel's, but not nearly as good as NXP's.
One thing I particularly like about NXP's Cortex documentation is its organization. For example, every peripheral has a section in the manual titled "Basic Configuration" that goes through how to initialize and configure that peripheral. Everything that needs to be done to initialize a peripheral is covered in outline in this section, and the PDF version of the manual has extensive hyperlinks in this section to the sections that go into more detail.
With other manufacturer's documentation I find myself paging back and fourth through the manual to find everything I need to initialize a component, often with a highlighter pen to mark isolated, but important details. Not so with NXP documentation -- it's all conveniently in one spot. |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
