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.
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.