| ??? 01/29/06 21:56 Read: times Msg Score: +1 +1 Informative |
#108660 - Well done! Responding to: ???'s previous message |
Stanley said:
This one moves much smoother, smarter, and faster than the one I made before (if you still remember). Looks very professional, dear Stanley! What are the main differencies to your earlier version? Stanley said:
I didn't take any course about assembler programming. That's a good basis to become a good programmer, believe me. Stanley said:
I found it is very very difficult to debug a assembler code longer then serval hundreds. How do you debug yours? The best way to debug is to avoid bugs. Spend as much time and brain work as you can on analyzing, thinking and coding that no mistakes will occur. Try to become a part of it, try to feel what your application makes, then you will get an idea about timing needs, priorities and other finer details. If mistakes occur, then try to separate code into entire and closed modules and test them individualy. Play with the code of each module like you find the right part of a puzzle or you find out how something technical works. Play with it like a child. The more you change the more information you gain about the code and the mistake and the easier it is to find the mechanism of mistake. Stanley said:
One more question, how do you keep your assembler code? I mean, in what form? When I read those codes I wrote serval months ago, hardly can I understand what I wrote and what those code means. Do you save your code in module? macro? or what? Understand your code as different levels of abstraction. Draw a flowchart for each level. The highest level of abstraction could be: "Every 10msec I check the intensity of light detetctors to find the position of light source. Then I drive the according motor." The lowest level of abstraction is the assembler code itself. Find as many abstraction levels as you need. Distinguish between the more modules (subroutines) the lower the abstraction level becomes, means make the more details to appear the lower the abstraction level becomes. When only having the assembler code the only you will see is "details". You cannot see what the assembler lines are once written for, means you will not see the forrest because of the many many trees... In any case, commentate each single assembler line, even if this looks totally ridiculous at the time when you write the code. Try to make the comment to be not only an echo of the machine instruction, but to give a little bit more information, which makes some instructions in a row to become a certain meaning. Many people often profit from saving the original manuscript, with all the many faults and comments. Then, when looking at it you will remember the whole story of "When Stanley wrote the enhanced servomotor head program". For the human brain it's easier to remember a story with all the many details than an endless list of "meaningless" instructions. Kai |
| Topic | Author | Date |
| Servomotor head version III | 01/01/70 00:00 | |
| Nice Work | 01/01/70 00:00 | |
| Manageing code and debugging | 01/01/70 00:00 | |
| Divide into modules | 01/01/70 00:00 | |
| multi tasking | 01/01/70 00:00 | |
| IRRC routine are much longer | 01/01/70 00:00 | |
| No waiting for IR | 01/01/70 00:00 | |
| two mcu | 01/01/70 00:00 | |
| Maybe this will help you | 01/01/70 00:00 | |
| this is not IRQ save | 01/01/70 00:00 | |
| RS232 | 01/01/70 00:00 | |
| Design First | 01/01/70 00:00 | |
| Design | 01/01/70 00:00 | |
Pardon | 01/01/70 00:00 | |
| Well done! | 01/01/70 00:00 | |
| The "3.0" | 01/01/70 00:00 | |
| Smart! | 01/01/70 00:00 | |
| hardware | 01/01/70 00:00 | |
| Mainland China | 01/01/70 00:00 | |
| And Well done Kai! | 01/01/70 00:00 | |
| My experinece | 01/01/70 00:00 | |
| very impressive | 01/01/70 00:00 | |
| Program and Code Structure | 01/01/70 00:00 | |
| Spaghetti anyone ? | 01/01/70 00:00 | |
| manually interpret machine code? | 01/01/70 00:00 | |
| hand coded mechine language | 01/01/70 00:00 | |
| Keep up the good work | 01/01/70 00:00 |