atferrari
Joined: 30 Jun 2004
Posts: 188
Helped: 3
Location: Buenos Aires - Argentina
|
 02 May 2008 13:18 Various questions - Programming |
|
|
|
Let me tell in advance that I work with PIC micros (currently 18F family) in Assembly only. Tried to learn C, some 20 years ago and abandoned due to difficulties to understand pointers.
BASIC was part of my approach to these matters with an Timex Sinclair in 1983 and 84. I have no formal (whatever that means) education in Electronics / programming and connected subjects.
Visual Basic, I learnt it but never used in a serious application.
I am 100% selft taught. (And I regret it. Too much time spent in trying/learning with no guidance.)
These are my questions (?) if you like to call them like that:
a) Teams writing C compilers (or whatever high level language for the case) for embedded design are supposed to know the hardware of related micros VERY WELL, probably better than common users. Is it true?
b) Read many times pejorative comments about, GOTO and resulting "spaghetti code" which does not happen with HLLs. (There is an article writen by one of the fathers of C, demolishing the GOTO approach).
May I presume that all the GOTO, BRA and the like, DO exist in the HLL in question, BUT under the hood? The writer of the compiler did the dirty job already. Is it right?
c) In line with b), I've read a comment that the typical MAIN loop used in Assembly doesn't exist in HLLs. May I presume that also here, it is running under the hood again. From my lack of experience I can not see how a micro expecting things to happen could do it if not repeating a minimal list of checks or "waiting" along a string of time slots in a loop. Even more, if it actually has to do repetitive things like updating a display or just blinking a LED.
Program counters basically move on all the times, isn't it?
d) From the beginning I use detailed flowcharts for all my desgins, with increasing levels of detail. (I would no try anything without them).
Using the "bottom" ones, (maximum detail), when I write the respective code, I find myself virtually "translating", line by line, what is detailed in those charts.
Additionally, I convinced my self to comment 99% of the lines. Thanks to that, I can revise code quite easily. Or revisit it, years later with little difficulties. Not to speak about debugging!!.
(The sole case in 20 years I wrote code without them, was this year when studying the 18F4585 for CANbus applications. Initializing the CAN module was simply made following the sequence somewhere outlined in the datasheet.) (It worked in all modes, BTW).
Nobody seems to mention that flow chart approach. Is it too "childish"? Do not be affraid of being sincere here.
-------------
Could you please reply following the order of my questions? For my own sanity, I need that.
And please note: This is not an attempt to start another STUPID c / Assembler war (which I hate).
Gracias.
|
|
btbass
Joined: 20 Jul 2001
Posts: 851
Helped: 63
Location: Oberon
|
| 03 May 2008 20:27 Re: Various questions - Programming |
|
|
|
C is the language of choice for embedded applications because it is faster and easier to write, maintain and extend than assembler. It is a very simple language with only about 26 keywords. Pointers are the heart and sole of C and give it power and elegance. The concept of a pointer is very simple, it is just an address in memory. If you are programming in assembler, you must be using pointers all the time. I realy think you should give c another go, it is like writing poetry.
Microchip has good support for C, Hi-Tech for the low/mid range, Mcc18 for the 18F's and C30 for the 16 bit series. C30 is excellent, a port of the GCC compiler.
I do like writing in assembler myself, the pic30f 16 bit series has a great instruction set.
My answers to your questions.
A) Teams writing c compilers only care about the instruction set and not the hardware. The Pic families share a common instruction set. C is not about hardware.
B) Trouble with GOTO is there is no WHERE FROM. When you need to debug it is hard to trace program execution for non trivial programs. They lack structure.
C) A while(forever) loop is one approach to a program, but not the only one. I tend to favour state machines, where the states are atomic and have a well defined transition into and out of the various states. These programs are easy to maintain and extend as side effects are kept to a minimum. Another approach is multitasking with an RTOS.
D) The software design description and flow charts should be the first thing done for any non trivial program. Flowcharting has come a long way, you can now buy programs the implement the Unified Modeling Language (UML) and generate the c code from your diagrams and interfaces. It's harder to learn UML than it is to learn C? MATLAB has StateFlow, again it can generate MISRA compliant C code from your state diagrams. It can also animate your state diagrams and you can see the program in action.
|
|
