I am a starter in microcontroller programming. I understand programming but first I am starting with Keil uVision3-software and Evaluation board MCB-STR9. Is there any user guide or tutorial which could help me to start and program and see results on board. I could not find online. Can someone help me please?... Thanks...
Indeed, what we'd call a slight incline, rather than a shear face.
Then there are LaunchPad or Discovery type boards, or simple breakout PCBs. There are plenty of ways to do basic exploration and experiments, without getting overly complex or expensive.
If you've already got an MCB-STR9, then you can use that to learn. Just bear in mind that whatever processor you choose now, you should be prepared to learn something new when you start a real project.
The first ARM part I started with was the STR9. I began by downloading the reference manuals and studying them. I also built, downloaded and ran the simple example Keil programs. Then I started adding little bits to try out what I had read in the reference manual. Controlling a port pin, starting a timer, updating the display.
As I said, you'll probably have to learn something else when you start a real project. Don't worry about things that look a bit strange. The STR9 does have a few quirks and I never got reasons for them.
Step at a time is a good way.
Give it a try. Enjoy yourself.
"Have not given importance to any architecture as such. Dont know where did you figure out an 'importance giving statement'? :O"
Well you noted that the Cortex architectures where the latest - and then directly recommended the LPC21xx which are several generations older.
That was the reason why I wondered why there would be a reason to go for an old ARM7 core with old peripherials instead of a newer Cortex core with much improved peripherials. The Cortex-M3 chips aren't harder to program. And they aren't more expensive. But they do offer some advantages compared to LPC21xx. One of the advantages with jumping forward is that it is possible to decide if the chip should be programmed with "manual" register accesses or using a standard library.
And it was also the reason I suggested LPC23xx if someone wanted to play with an ARM core, where it is possible to write assembler using either ARM or Thumb instrictions. Or go for Cortex-Mx chips and use Thumb2.
The only real reason to go for LPC21xx is if someone already have one or know how to get one for free. But it doesn't really offer any advantages compared to any other processor family.
I would suggest a slightly different order:
1. configure a port pin as output pin and turn it On & Off.
2. configure a port pin as output pin and turn it On & Off after some delay, use timer to generate delay. (To learn Timer)
3. Use the UART to transmit "HELLO WORLD", and learn how to receive & view the transmitted data on a PC
4. configure UART to transmit the last received data. (To learn UART)
5. write "HELLO WORLD" on 16*2 character LCD.(To learn LCD interface)
6. Display the data received form UART on LCD. and so on.... after these basic exercises, you can start learning I2C protocol, SPI protocol, etc...
At each stage practice using the Debugger to follow the execution of your program, examine variables, registers, etc.
The Debugger is an essential tool - it is important that you learn to use it well as soon as possible!
But do not forget that the most important and powerful development tool is the one between your ears.
I've seen way too many developers who have got into the habit of scratching together some code and then reaching straight for their debugger to find their bugs. A little though, care and understanding at the start can dramatically reduce the need for later bug hunting.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
The most difficult code to debug is 'clever' code. Also 'clever' code is the code most often needing debugging.
good code is readable not 'clever'.
a good example is someone that is 'clever' enough to omit as many brackets/paranthesis as the C standard allow and end up with unreadble code, and, most likely, missing a pair of brackets that actually are necessary
Erik
"and, most likely, missing a pair of brackets that actually are necessary"
The missed brackets comes one step later - when it's time to modify the code to extend it with some new functionality. Suddenly, that change did break an "else" or similar.
A favourite is code that contains multiple, nested, ?: constructs where the different parts also contains assigns or pre/post-increments modifying one or more variables on the right-hand side of the assign.