This is more of an article than a request for technical support. I have been getting assistance from you all and wanted to summarize my study and learning of the basics of MCU's. A few months ago I didn't know much about MCU's at all, and now I want to document those early stages of learning because I think there are things I know now that could have helped me along the way.
I'd like to open a discussion – not about the specifics of electronics or microcontrollers – but to talk about those frustrating moments when you’ve been trying to figure out something for hours if not days, patiently hacking away at whatever it happens to be.
I have got to be the single most patient person in the world. I am a relatively social guy, but I have a need and a passion for electronic engineering. I do it as a hobby. I enjoy technical things and little nitty gritty details that have relatively no purpose in life. The obscure details one would only know after discovering them ten hours after endeavoring into some kind of sustained, frantic, aggravated assault on pdf files, google searches, web sites in foreign languages, youtube videos and “hunt and peck” trial and error attempts at resolving the problem du jour.
In learning the Microchip MCU I have found these obscurities in just about every task I have encountered. Couple that with my self-taught EE background and previous programming experience in PERL, I can say the last three months have been challenging and at times hell. I Don’t have mentors and I know no one who is into electronics engineering, and everyone into programming is doing internet stuff.
The existence of these forums is a great asset to the self-taught like me. In my previous audio career, when I was studying audio engineering I found the “Digidesign User Conference” and 6 months later I had learned a LOT. After three months of intense learning, I feel as if I’m a tenth of the way there this time.
It may be that there are so many different iterations and options that make it so you can’t walk directly into doing this because you end up tripping over the fifty other related (yet impossible to realize immediately) things you need to learn - to do your simple task.
There must be some sort of progressive learning order or “way”. Once you get used to turning off the Analog to Digital converters (ADCON) and setting up your tristate ports, once you get past the configuration word you still have no idea what all those acronyms by the pin diagrams mean. You probably don’t understand what a special function register is (SFR), and the data sheets look more like a foreign language than a helpful thing. I have two tips that would have helped me immensely at the beginning: 1. Learn what a Register is. 2. Learn where to find the definitions for them. Print the Special Function Register Map and the include file for your MCU.
These key pieces of information made everything click for me. I still am a novice at this, but I have finally found the comfort zone I was looking for. Three quarters of the acronyms in programming an MCU are defined in those library files, (that define the SFR’s) and practically nothing on the internet points the way to them. Also, look in the Hi-Tech C folder in your programs folder. In addition to the manuals there, you can find in the include folder definitions for your configuration words and special function registers. Sometimes HI Tech types the SFR’s different from the Microchip manual, so you need to use those as a guide to reference the SFR’s described in the manual.
Then there are other big decisions that need to be made early in learning about all this that are missing from the guides of the novices: Which compiler to use? Which MCU to use? Assembler or C? These three decisions square out to exponentially confusing options, leading to a maddening learning curve that daunts even the most patient. First you are looking for examples of the things you want to do. You may find an example that does what you want to do but it uses a different compiler. Then you find one that uses assembly language and you don’t know assembly language. Then you get in to your project and realize that you have been using the wrong chip the whole time because you didn’t plan ahead – or worse, the compiler doesn’t support that chip completely. These things aren’t your fault – you are winging it to begin with. So you end up swapping out chips and starting from the beginning with what you learned looking more like a battlefield with dead bodies strewn throughout. Then to make things worse, god help you if your MCU is a bit old and out of date.
I have been dealing specifically with the Hi Tech C compiler. Optionally I could have used the C18 compiler or who knows what else. Occasionally an example is made for these other compilers which confuse everything even more. You end up asking yourself questions like “Am I using the wrong compiler?” and “Should I have just learned Assembly Language to begin with?” There are issues with Hi Tech C, but I have no doubt there will be intense issues with any other compiler.
Getting a little further into the programs I have been writing, I recently arrived at the point where I wanted to use a debugger for real. And with it came an entire set of learning curve lessons. The compiler optimizations really threw me off big time. If you haven’t paid $500 dollars for the real Hi tech compiler like me, and want to use a debugger, good luck. You have no control of optimizing the code, FWIG. Basically you write code and then the compiler rewrites your code in an intermediate language, and then rewrites it again. This process may make your program work better or not. I want to turn all optimizations off, so I can test my weak C knowledge as well as the functionality of the chip. My attitude towards this is leaning to: If you want to test something because you aren’t sure how to write it in C to begin with, you are almost better off working out the nitty gritty of academic C language related issues in a separate compiler (like mvs) that does not optimize like these do. As for learning C versus Assembly, I am getting to know assembly language now, not by choice but because you really do need to learn C and Assembler to pull this off. It’s just another lesson no one taught me.
In the concept of getting “taught” I went looking for literature that would help me out. I found the book “Designing Embedded systems with PIC Microcontrollers” by Tim Wilmshurst to be a useful point of reference when you are trying to do something and need the basic concept behind it. It gives a good general conceptual view of all the basics and can be read in any order without getting too over your head.
Unfortunately, Most bookstores around me stock the book “Programming and Customizing the PIC Microcontroller” by Myke Predko, which goes from “I can handle this” to “We are no longer on the planet EARTH” in a heartbeat. His “123 Microcontroller experiments for the evil genius” is a little better at going at basic things but is out of date. He also leads you to HI-Tech C. I’m guessing that more than half of the people use HTC because they probably read these books. I have unanswered questions: Is MCC18 better? Are there better compilers out there? Why do people use Hi Tech C over another compiler? Why do some people use MCC18 or other compilers? It’s free right? Why would I pay 500 bucks for Hi Tech when MCC18 is free?
The moral of the story, I think, is to have an open mind and be willing to accept global and sudden changes in plans during the beginning stages of learning this. If you are learning something but the solution isn’t coming to you, keep your focus and keep working at it. Once you begin to see the issues at a resolution you will know how to deal with them better. All of those little off shoots of learning, things that you tried but didn’t work, or things that just took forever to get going, are worth it. I am beginning to believe that learning to program a MCU without much experience is all about learning all of it at the same time, by trial and error, and by finding the sage advice of people you can come in contact with. I am very thankful I have found this, the Hi tech Forum, and the Forums on Microchip.com. Most of the time you can collect the information you need to solve the problem but it might just take that extra mind to pinpoint the problem and put a little bow tie on it.
Best Regards,
Keny
I'd like to open a discussion – not about the specifics of electronics or microcontrollers – but to talk about those frustrating moments when you’ve been trying to figure out something for hours if not days, patiently hacking away at whatever it happens to be.
I have got to be the single most patient person in the world. I am a relatively social guy, but I have a need and a passion for electronic engineering. I do it as a hobby. I enjoy technical things and little nitty gritty details that have relatively no purpose in life. The obscure details one would only know after discovering them ten hours after endeavoring into some kind of sustained, frantic, aggravated assault on pdf files, google searches, web sites in foreign languages, youtube videos and “hunt and peck” trial and error attempts at resolving the problem du jour.
In learning the Microchip MCU I have found these obscurities in just about every task I have encountered. Couple that with my self-taught EE background and previous programming experience in PERL, I can say the last three months have been challenging and at times hell. I Don’t have mentors and I know no one who is into electronics engineering, and everyone into programming is doing internet stuff.
The existence of these forums is a great asset to the self-taught like me. In my previous audio career, when I was studying audio engineering I found the “Digidesign User Conference” and 6 months later I had learned a LOT. After three months of intense learning, I feel as if I’m a tenth of the way there this time.
It may be that there are so many different iterations and options that make it so you can’t walk directly into doing this because you end up tripping over the fifty other related (yet impossible to realize immediately) things you need to learn - to do your simple task.
There must be some sort of progressive learning order or “way”. Once you get used to turning off the Analog to Digital converters (ADCON) and setting up your tristate ports, once you get past the configuration word you still have no idea what all those acronyms by the pin diagrams mean. You probably don’t understand what a special function register is (SFR), and the data sheets look more like a foreign language than a helpful thing. I have two tips that would have helped me immensely at the beginning: 1. Learn what a Register is. 2. Learn where to find the definitions for them. Print the Special Function Register Map and the include file for your MCU.
These key pieces of information made everything click for me. I still am a novice at this, but I have finally found the comfort zone I was looking for. Three quarters of the acronyms in programming an MCU are defined in those library files, (that define the SFR’s) and practically nothing on the internet points the way to them. Also, look in the Hi-Tech C folder in your programs folder. In addition to the manuals there, you can find in the include folder definitions for your configuration words and special function registers. Sometimes HI Tech types the SFR’s different from the Microchip manual, so you need to use those as a guide to reference the SFR’s described in the manual.
Then there are other big decisions that need to be made early in learning about all this that are missing from the guides of the novices: Which compiler to use? Which MCU to use? Assembler or C? These three decisions square out to exponentially confusing options, leading to a maddening learning curve that daunts even the most patient. First you are looking for examples of the things you want to do. You may find an example that does what you want to do but it uses a different compiler. Then you find one that uses assembly language and you don’t know assembly language. Then you get in to your project and realize that you have been using the wrong chip the whole time because you didn’t plan ahead – or worse, the compiler doesn’t support that chip completely. These things aren’t your fault – you are winging it to begin with. So you end up swapping out chips and starting from the beginning with what you learned looking more like a battlefield with dead bodies strewn throughout. Then to make things worse, god help you if your MCU is a bit old and out of date.
I have been dealing specifically with the Hi Tech C compiler. Optionally I could have used the C18 compiler or who knows what else. Occasionally an example is made for these other compilers which confuse everything even more. You end up asking yourself questions like “Am I using the wrong compiler?” and “Should I have just learned Assembly Language to begin with?” There are issues with Hi Tech C, but I have no doubt there will be intense issues with any other compiler.
Getting a little further into the programs I have been writing, I recently arrived at the point where I wanted to use a debugger for real. And with it came an entire set of learning curve lessons. The compiler optimizations really threw me off big time. If you haven’t paid $500 dollars for the real Hi tech compiler like me, and want to use a debugger, good luck. You have no control of optimizing the code, FWIG. Basically you write code and then the compiler rewrites your code in an intermediate language, and then rewrites it again. This process may make your program work better or not. I want to turn all optimizations off, so I can test my weak C knowledge as well as the functionality of the chip. My attitude towards this is leaning to: If you want to test something because you aren’t sure how to write it in C to begin with, you are almost better off working out the nitty gritty of academic C language related issues in a separate compiler (like mvs) that does not optimize like these do. As for learning C versus Assembly, I am getting to know assembly language now, not by choice but because you really do need to learn C and Assembler to pull this off. It’s just another lesson no one taught me.
In the concept of getting “taught” I went looking for literature that would help me out. I found the book “Designing Embedded systems with PIC Microcontrollers” by Tim Wilmshurst to be a useful point of reference when you are trying to do something and need the basic concept behind it. It gives a good general conceptual view of all the basics and can be read in any order without getting too over your head.
Unfortunately, Most bookstores around me stock the book “Programming and Customizing the PIC Microcontroller” by Myke Predko, which goes from “I can handle this” to “We are no longer on the planet EARTH” in a heartbeat. His “123 Microcontroller experiments for the evil genius” is a little better at going at basic things but is out of date. He also leads you to HI-Tech C. I’m guessing that more than half of the people use HTC because they probably read these books. I have unanswered questions: Is MCC18 better? Are there better compilers out there? Why do people use Hi Tech C over another compiler? Why do some people use MCC18 or other compilers? It’s free right? Why would I pay 500 bucks for Hi Tech when MCC18 is free?
The moral of the story, I think, is to have an open mind and be willing to accept global and sudden changes in plans during the beginning stages of learning this. If you are learning something but the solution isn’t coming to you, keep your focus and keep working at it. Once you begin to see the issues at a resolution you will know how to deal with them better. All of those little off shoots of learning, things that you tried but didn’t work, or things that just took forever to get going, are worth it. I am beginning to believe that learning to program a MCU without much experience is all about learning all of it at the same time, by trial and error, and by finding the sage advice of people you can come in contact with. I am very thankful I have found this, the Hi tech Forum, and the Forums on Microchip.com. Most of the time you can collect the information you need to solve the problem but it might just take that extra mind to pinpoint the problem and put a little bow tie on it.
Best Regards,
Keny
