I have read all those projects on this site http://nand2tetris.org/course.php There have been explained in very simple way to understand the basic of computer architecture but there is no information for c language. I am not become expert but I am trying my best

I think you may have just touched on one of the key issues that is causing you problems.

I think you are approaching all of the various topics you have been asking about as disjoint and unconnected things. That structured programming is completely separate and unrelated to object-oriented programming. That embedded system programming is completely separate and unrelated to hosted (non-embedded) programming. That C programming is unrelated to understanding how a typical computer architecture works.

But all of these are intimately related -- most have more in common than they have different. Programming is not about a particular language, it is breaking down a big problem and solving the smaller problems using clear and well-defined steps that can then be used to build up solutions to the overall problem. If you learn how to write programs in one language without learning how to solve problems separate from the language, then all you will likely have learned is a bunch of disjointed syntax rules and your abilities to solve problems using programs even in that language will never develop very far. But if you instead focus on understanding how to identify the steps that solve problems completely separate from any particular language, then you will find that you can solve problems using many languages with relatively little effort.

When I was in high school I took a Computer Math course, which was really a course in computer programming using BASIC. What I didn't realize at the time was that the way the teacher taught it he was really teaching programmatic problem solving and we just happened to be using the BASIC language to implement those solutions. I didn't know this at the time; I thought I had just learned how to program in BASIC. When I started college we had to take two semesters of Fortran programming. After the first two classes I realized that all I was doing was solving the problem "in BASIC" and then translating my solution to Fortran using a cheat sheet I threw together that showed me what the syntax was for each of the handful of basic control structures. So I took the challenge exam to test out of the course, not expecting to do very well on it, and was one of just a few that passed it, even though I had never heard of Fortran just a couple weeks prior. It wasn't until several weeks later when I was back visiting my high school and told my computer math teacher about that that he explained to me that what he had really been trying to teach was algorithmic thinking and not how to program in a particular language. He said that most people have a very hard time seeing the difference and just focus on the syntax rules of the language they are learning, but that I had managed to grasp that difference and focus on the problem solving aspect instead.

That's what you need to try to focus on. Figure out how YOU would solve the problem by hand without a computer at all and how you would break it down into simple, easy to explain steps so that someone else, without even knowing what the problem is that is being solved, could follow your steps and come up with the correct solution. Only then consider how you would implement each of those steps using a program and a certain programming language.

As an example, let's say that I wanted to find the square root of a number to three decimal places using nothing except addition, subtraction, multiplication, and division. How might I do it?

I could come up with an algorithm that used just those operations and could lay them out in sufficient detail such that if I gave them to you and gave you a number, say 12345, you could work through the steps I had written out and come up with the number 111.108 even if you had not idea that what I was looking for was the square root of the number I gave you. Once I've developed the algorithm in that fashion, then is when I should look at it and see how to implement it in a particular language -- and it wouldn't really matter what language it was. If it was a language I was somewhat familiar with, it would probably be the matter of a few minutes to perhaps an hour to implement it. If it was a language that I was completely new to, it might take a few hours or even a day or so to become sufficiently knowledgeable of the language to implement that algorithm.

But here's a key point -- I would almost certainly learn a lot more about how to program in that new language going through that than I would in several weeks if I were to just decide that I wanted to learn how to program in that language by reading a book about it. The reason is that I would have focus. I would be looking at my algorithm and asking very specific questions such as how do I get a number from the user? Or how do I multiply two numbers together and store the result back in the same variable? Or how do I determine that two numbers agree to the third decimal place? Or how do I output a non-integer value? Or how do I execute a set of instructions multiple times? Or how do I choose between executing one instruction instead of another? Each of these are tiny little problems that can be researched and solved in a matter of minutes in most cases.

You need to bring focus to your study of programming.

 

You need to bring focus to your study of programming.

In the past few days, I have changed my learning approach. I solve the problem on paper and then I write program on PC ie Print number from 1 to 10 using while loop. Print number from 1 to 10 using for loop. program to check positive and negative number. Program to check even and odd number. Program to reverse number, string. Program to find palindrome number. program to find maximum and minimum number in list. program to arrange number in ascending and descending order... so on. I am practicing on it daily.

I think it's not fair to solve only c problem's so I think I should start to write embedded c programming. I do not have much problem with c but I am having trouble with embedded C programming. I think I should start embedded programming again. I can writing interfacing program for Switch,Push Button, LED,DC Motor and LCD. I want learn programming for GPS RFID RTC and Keypad.

You will be very helpful if you tell what to do first. Once my goal is fixed then I will be able to find it. Whatever advice you all will give. I will follow your advice

 

In the past few days, I have changed my learning approach. I solve the problem on paper and then I write program on PC ie Print number from 1 to 10 using while loop. Print number from 1 to 10 using for loop. program to check positive and negative number. Program to check even and odd number. Program to reverse number, string. Program to find palindrome number. program to find maximum and minimum number in list. program to arrange number in ascending and descending order... so on. I am practicing on it daily.

I do not have much problem with c but I am having trouble with embedded C programming. I think I should start embedded programming again. I can writing interfacing program for Switch,Push Button, LED,DC Motor and LCD. I want learn programming for GPS RFID RTC and Keypad.

You will be very helpful if you tell what to do first. Once my goal is fixed then I will be able to find it

No, I don't think you should do that. Instead of re-starting over and over, sit down and think about what you have learned so far and where you are having problems. Look at those simpler things you already have done and be sure you understand everything about the solution. From my observation, you use lots of code found on the internet rather than writing your own from scratch and that's why you don't seem to fully understand the code or the solution to the problem. Your comment about programming for GPS, RFID, RTC and Keypad is notable. Because you haven't mastered the basics of programming and the C language, each of these things appears a different problem. For sure, each one has their own specific requirements. But the difficulty you have in the threads on those subjects is unrelated to those specific things. Your difficulties are due to not having mastered the basics. It doesn't matter what a GPS sentence says what if you don't know how to read a string from a UART.

Systems design and programming builds big complex things from lots of little, well-understood things. Those little, well-understood things are used over and over as tools and parts to build the more complex stuff.

I would recommend you re-visit some of your simpler threads where you left them unfinished or got lucky in getting them to work. LED toggling, switch input and debouncing, interrupts, timers, UARTs, C basics, C data structures, pointers, arrays, structs, program flow, loops etc.etc. need study.

Do you always begin a design by sketching it out on paper with a flow chart, pseudo-code or similar? Can you trace the code flow with your finger on the paper? Does the code match the design? Did you finish the coding and test it completely? Do you know how the debug process works?

For example, you say you have done LCD code. I have seen lots of your threads where the LCD code is different for each project. Why? Once you have a design and have coded it and it works why does it get different each time? LCD interfacing is the same regardless of the project. What your code looks like is that you've cobbled it together from various sources without a deep understanding of what you're doing. Design it, code it, debug it then archive it for re-use.

There are many other cases like that, even with the simple LED / switch stuff. Instead of understanding then fixing problems, you repeatedly ripped it up and tried again from scratch.

So again, before you go farther or start again from zero, go back do the basics. Until you can describe a problem, design a complete solution and code it using well-understood methods, you'll continue to have difficulties. Start at chapter 1 of a good text and get going. Look at some of those online lectures from Academic Earth. Focus on one problem at a time. Don't worry about the time. It's better to progress slowly in one direction than bounce off the walls at high speed. You have to do that to be a good programmer in any environment. Embedded systems add a hardware element that makes it more difficult - especially so if you don't have programming basics down pat.

Again, not scolding, trying to help. Good luck!

 

JohnInTX Is right I use the same code in c for the Lcd on a bunch of chips AVR and Pic and stm only changes is the port stuff to mach the chip

I always been more of a hacker But it's like he said you really don't learn as much that way.

I been looking at the data sheet and try to write code that works I2c stuff is fun

You really need to learn your Ide keil it has lots of tools to test your code.

This stuff don't happen over night The thing about code you find haft of don't work because they leave out part's
Like Mplab-X lots of code they show was for older 1.30 and down compiler I've learned a lot about C in the last year
It's not a fast and short road.