Various questions - Programming

[atferrari]

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.

 

[arhi]

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?

in one word: yes
in more words:
It should be true, but as in any business, some slackers pull trough so not all compilers produce the "best" code. Speaking about compilers, there is also issue about optimization, as usually they go with some "general" optimization rules that apply to many cpu's and ignore some device specific optimizations, they do that sometimes because they do not know, sometimes because the optimization algorithms are patented and cost a lot of money to pay for the licence even they are not hard to implement.

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?

using GOTO in C writing general application deserve all the pejorative comments that exist, but writing app for windoze desktop and writing app for 12c508 PIC is not the same. When using HLL for development of "desktop app" one expect the compiler to do all the necessary optimizations and one assume that developer should stick to the programming style of the tools he uses (weather that is C or C++ or something as ugly as lisp). Development for embeded systems, especially for uC's like low/mid range PIC's where you are limited on all sides, using goto might save significant amount resources hence it is allowed. Anyhow, one should try to stick with the dev tools style where applicable.

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.

The HLL usually have main procedure that defines entry and exit point of the application. As when you do embedded stuff you do not have exit point, it is your job to make sure that program never end's. There are number of loop's in the HLL's for doing that .. for e.g.

...
while(1) {
 ... 
}

is pretty much the same as

...
loop:
   ...
   jmp loop

Nobody seems to mention that flow chart approach. Is it too "childish"? Do not be affraid of being sincere here.

why would the flow chart approach be childish? One better plan the app before one start coding one. Using HLL will just decrease the depth level of the flow chart you have to make, but that's it.

 

[Mike - K8LH]

I use a flow chart for my programs too and I would hope that no one thinks that's childish.

Regards, Mike

 

[Torben]

I use a flow chart for my programs too and I would hope that no one thinks that's childish.

Regards, Mike

Nope. In university they made us learn UML (actually a precursor to UML). Much as I hate doing it it's often a good idea.

I've often found that spending a few hours with a pencil and pad of paper before starting to code helps smooth things immensely. Especially since when you have a pad and pencil with you at the pub you look like you're thinking great thoughts or working on a book; when you have the laptop computer at the pub some yahoo will pour a Guinness into it.


Torben

 

[Pommie]

Nope. In university they made us learn UML (actually a precursor to UML). Much as I hate doing it it's often a good idea.
Torben

Looks like someone took flowcharts and complicated them to a ridiculous degree. Or, to put it another way, it's a flowchart that's been foobared.

Mike.

 

[Pommie]

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

Commenting every line sounds like a good idea but generally isn't unless you intend your code for complete beginners. Often comments just repeat the code in different words. This hides the important comments.

I just had a look through a current project and found,

;will return a 10  bit (+sign) value equal to sin(w)*1024
GetSine		movwf	Temp
		btfsc	Temp,6		;are we in 2nd or 4th quadrant
		sublw	0		;negate - note 64 will become 192
		andlw	0x7f		;and now back to 64
		addlw	low SineTab
		movwf	Pointer
		movlw	high SineTab
		btfsc	STATUS,C
		addlw	1
		movwf	Pointer+1
		call	SetEEAddress
		call	ReadEEWord
		btfss	Temp,7		;are we in the 3rd or 4th quadrant
		return
; need to negate Acc
Negate
		comf	AccLo,F
		comf	AccHi,F
		incfsz	AccLo,F
		return
		incf	AccHi,F
		return

I don't think any meaningful comments can be added to the above code. Had I used more obscure variable and subroutine names then comments would have been necessary.

The same code with bad names and too many comments.

		movwf	A		;A (and A+1) is EEPROM address
		movlw	Tab/256		;get high byte of table
		btfsc	STATUS,C	;did we get a carry
		addlw	1		;yes, so add 1
		movwf	A+1		;save in high byte
		call	SEA		;setup EEPROM address
		call	REP		;Read EEPROM

Many will disagree with my comments (lol).

There is an excellent book called "Code Complete" by Steve McConnell that is well worth reading. See if your local library has a copy.

Mike.

 

[3v0]

In higher level languages there is the concept of self documenting code. It builds on what Mike was talking about.

Picking variable names with real meaning is one of the more difficult things to do. More so as the day goes on.