I know it's been a month since the last reply, but with the volume of stuff to learn I'm sure you're still looking for insights.
I skimmed the bulk of the responses and I'll throw my $0.02 in.
In some respects, I'm feeling your same pain. Recently getting into the hobby side and picking up PICs, but the last time I used one was senior project for my BS and that was like 15ish years ago. Things were a lot different.
Personally, I think the bulk of your confusion and frustration is due to the nature of what you're trying to grasp. I think if you break it apart and look at each of these things in their own light, then it starts to come a little easier as to how all the pieces fit together:
- What's the architecture of the cpu like and how does it work? NOT the controller as a whole, just the cpu.
- What's the ASM language like and how does that work with the cpu? (sounds like you're getting a good handle on all this part, and yes it goes hand in hand with the prev bullit)
- How does the cpu interact / work with the hardware around it? In this case I speak generically - not just the cpu in a PIC, but any cpu.
- How does this peripheral hardware itself operate? (e.g.: how does a UART function, or an ADC, etc.)
- How do I write code (asm or otherwise) to get the cpu to interface and drive all this extraneous hardware?
- then on top of all that you have the specific tool environment, which has a learning curve of its own. But if you have all the other things handled, this will come more naturally and it will be a matter of just learning its specifics.
When learning all this sort of stuff in college, I was learning each piece in its own light. Had programming classes that were all about strictly programming concepts (speaking higher level languages and platform independent here). Had an ASM class to learn how machine code looks and works with the architecture of a CPU. Had a class called "computer interfacing" which was learning all about how to write code to have a cpu drive all its periphery hardware (in this case it was all in ASM). Then in parallel with all that I had some digital logic classes. It was at the tail end of my Advanced Logic design class that we got our first taste of a u-controller. But by that time all the foundation had been laid so it was a matter of just learning the specifics of what hardware was on the controller and how those specific tools worked (cross compiler, assembler, linker, etc.).
So my advice, to avoid getting too frustrated - realize you're dealing with multiple things at once and to look at them in their own light first before trying to figure out how to put it all together.
As to the whole thing about hardware people making better programmers......errrrrr.....I won't say that statements wrong, but I won't exactly agree with it either. Depends on what's needed. I don't think I'd want a hardware engineer that's had a couple C classes working on the code the bank uses to manage my bank account.
Home
Help
Search
Login
Register
