--0__=80256A03004C70318f9e8a93df938690918c80256A03004C7031 Content-type: text/plain; charset=us-ascii Hi, (Embedded "Alan B. Pearce" @MITVMA.MIT.EDU> image moved 02/03/2001 13:45 to file: pic29515.pcx) Please respond to pic microcontroller discussion list Sent by: pic microcontroller discussion list To: PICLIST@MITVMA.MIT.EDU cc: Subject: Re: [PIC]: Switch / If Statement revisited Security Level:? Internal >2. Quick (first) to market (Yes, we all know that if you have a massive >library of assembler "functionality" because you have been doing it for >5x10^6 years that can be bolted together, that is as fast as developing Until you find "module A" uses a different data format to "module B" which is different again to "module C" which is different again ...... because they all come from different projects over the years which all had different programmers who never new each other because of staff turnover etc etc etc. ## Is this not what documentation and version control is for? ;-) Being serious, yes...that is always going to be a problem. If the application layer is designed to be flexible, however, you can get away with plug in functionality at the lower levels to overcome this. >3. Universally understood - not everyone understands PIC assembler, >especially where people are new to a project or they have to 'pic'k >something up when the "PIC wizard" has left abruptly. The high level language is always generally easier to see what is going on with less effort than trying to get to the same level of understanding with assembler. Especially when coming back to it a year or two later when the customer wants some improvements or subtle changes to bring out a new variant or model of the product. ## Hmmm. That sounds familiar. Even at that, though, I find that it is hard to track a problem in C when some abstract problem has been papered over. This is typically done when a fudge is required and programmers seem very reluctant to document flaws in their design; instead they produce some convoluted bodge that is indecipherable 2 months down the line. I find the biggest problem is seeing the "intention" (i.e. whole picture) of other people's code; in my experience, people tend to document things like: // Set I/O Initialise_IO(); // Obtain the power up time PowerUpTime = Read_RTC(); Why bother with the comments? It is blatantly obvious what is going on! Much more useful would be to educate people to write down the intention of what is going on in some obscure section of code (and no, that example was not obscure)......no matter if in C or assembler or..... Dan -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu --0__=80256A03004C70318f9e8a93df938690918c80256A03004C7031 Content-type: application/octet-stream; name="pic29515.pcx" Content-Disposition: attachment; filename="pic29515.pcx" Content-transfer-encoding: base64 CgUBCAAAAABBADEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABQgABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA= --0__=80256A03004C70318f9e8a93df938690918c80256A03004C7031-- -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu