More seriously, there are about two schools of thought:
First School (education-centric):
1) Learn to program.
2) Learn how MCUs differ from the computer you learned to program.
3) Learn the new tools (different programming language, probably. C instead of Java, for instance) that are appropriate to MCUs.
4) Learn the specifics of how the particular MCU you want to use is different from MCUs in general.
5) Learn how to use the tools specific you that particular MCU (IDEs, device programmers, etc)
6) Practice.
Second School (experimentation-centric):
1) get an "easy" platform like Arduino (or Basic Stamp, or BASIC52 system.)
2) Run the examples and follow the tutorials.
3) Find and modify code from the WWW that is close your application.
4) Ask for help, as needed. Try not to be annoying.
Frankly, the idea of people trying to write programs of any complexity without SOME formal training in programming or computer science is a bit scary. But it's a time-honored tradition, and the fact is that there are LOTS of "problems" that people want to solve that really don't require much (or any) CS, beyond using the tools that have been developed by other people. That's why the "easy" systems succeed.
Old-timers will remember when "computer scientists", "programmers", "systems programmers" and "coders" were three distinct groups of people. Computer scientists would develop some event scheduling algorithm. And then a programmer would figure out how to apply that to a problem like the scheduling of maintenance at an Oil Refinery. And then a coder would fix up the details of the progammer's framework so that it worked for a particular compiler, and handle all those annoying details like correct syntax. The Systems Programer would provide the tools and instructions for compiling and running the program. And did I mention the keypunch operator? ("typist" was a separate job, too.) It was not unusual (it's STILL not unusual) to find people in one area that really sucked at some other area. Computer scientists that could develop lovely theoretical algorithms, but had trouble applying them to real-world situations, and "couldn't code their way out of a paper bag."
Home
Help
Search
Login
Register
