Also, it seems to me that as assembly is more closely tied to hardware, higher level languages are more 'generic'... Learned programming ability might be more easily applied to other platforms. If there are hardware differences between chips, or the desire to use another company's product, programming in assembly would require more research into hardware and instruction changes. I used to be somewhat profficient in Vic-20 and C64 6502 assembly back in the day, but that didn't mean I could write a functioning program on an Z80. However, a Basic program could be run on all those, as well as a Z80 Sinclair, with only slight modification.

 

But at that you're hiding the underlying hardware, and severely restricting the scope and performance of your programs. The examples you gave were all interpreters, and really ran incredibly slowly (for the speed of the hardware they contained).

Essentially you're adding a 'layer' between the hardware and software - like the BIOS in a PC, or the DLL's under Windows. You don't access the hardware directly, or even have to know what it is - you just need to know the access methods. This is all well and good, and makes programming large systems easier - but is also why you now need a multi-GHz P4 to give not a great amount of extra speed compared with a 68000 running at 8MHz.

I don't know what level of PC programming you've ever done?, but going back a LONG time you could make HUGE speed increases by directly accessing the video RAM, rather than using the correct routines and methods for doing so. Obviously this limits the portability of the program - and the nature of modern PC's doesn't make it a practical proposition these days.

In any case, this rambling isn't really anything to do with the thread!.

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk

 

I agree with your comments, and when it comes down to pure performance, nothing is faster than well coded assembly. But if I had to guess, I'd say the vast majority of ucontroller projects at the hobbiest level hardly approach the maximum capabilities todays chips provide. As with any rule, I'm sure there are exceptions, but 99% would probably perform their intended tasks acceptably when coded with a good quality compiler.

 

Well optimised PIC C compilers produce very small, very fast code - although the code produced tends to be very difficult to understand!.

But my objections to PIC C compilers isn't about the code or speed, it's about not knowing how to actually write the programs. Because C doesn't force you to understand the hardware many people don't bother - and it shows in their poor programming. A small knowledge of assembler would provide the hardware understanding required - as would studying the hardware from a C point of view, but that doesn't seem to be freely available?.

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk

 

My experience has been nearly the opposite. You can quite easily understand the chip hardware and registers, and still create horrible asm code; wasting cycles, branching all over the place and ending up with a lot of redundant code that could have been streamlined. And some really neat asm effeciency tricks like self modifying code have little to do with the underlying architecture at all.

Imo, the art of programming is not based on knowledge of the hardware so much as it is a basic understanding and appreciation of logic and decision flow. In that sense, for some people the most easily written and understandable code may be preferable. Certainly, code that is more visibly comprehensible also lends itself to easier debugging as well, a point that also merits some consideration.

 

I'd just like to point out that I'm not trying to bash asm, especially for people comfortable with it. I'd also agree that it does enlighten many of the hardware aspects that higher level languages insulate from you. Certainly, that is valuable knowledge to acquire.

But as the issue at hand in this context is usually an individual weighted more towards electronic projects, if the goal is to create the logic or actions necessary to produce a desired effect or outcome, then imo the achievement of that goal with least effort might take some precedence over pure efficiency.

 

Which brings up another important distinction... does the person you're making the suggestion to already KNOW the higher-level language in question (such as someone familiar with C on a PC, but never touched a microcontroller before), or are they learning programming in general at the same time they are learning the specifics of programming on a microcontroller? In my mind, this also makes a big difference in what language they should start with.

For someone who has never programmed at all, assembly may seem daunting, however because it's the "official" language of pics, and there are dozens of books and walk-through guides out there, it's not a bad starting point. Trying to learn a language and the hardware at the same time is not necessarily a great idea, because it's easy to make both functional/syntax mistakes in the language, as well as mistakes related to how you're using the hardware. For what it's worth, ASM at least involves a rather orderly, logical flow, as long as you're not doing anything horribly fancy, and it's not hard to visualize what is happening at each step. It is harder to follow when the program gets huge, but for beginner projects where they're just flashing an LED or something, it should not be hard to visualize and follow what is going to happen with each instruction line.

I'd much sooner suggest to someone unfamiliar with both the language and the hardware to learn the language an easier way, like spending some time with C on a PC, and some time learning the hardware with ASM on a PIC, and then try putting them together afterward.

For someone who's already proficient in C on a PC or otherwise, I'd probably be much more inclined to suggest that they jump to C sooner, though a little while spent in assembly would still be a good idea.

And just like Nigel's been saying, the support for higher-level languages pretty much sucks. You can go to bookstores like Borders or Barnes&Noble, or a library, and pick from a number of different books on PIC programming in assembly... But there's not much out there for C or BASIC or other languages on PICs, and I think this is because for the most part, the compilers are third-party products that haven't been around that long, rather than a standardized language set by the manufacturer that's been around for a long time. And, the compilers that are more of a professional product (like Hi-Tech PICC) generally end up being made into increasingly expensive commercial products (such as close to $1000 for PICC). Who's going to write an entry-level book about a compiler hardly any hobbyists can afford? And who's going to write a book about a compiler that is free or cheap, but is still in development and isn't perfect and stable and isn't guaranteed to continue being worked on? If you think about it that way, it's still too bad, but it isn't all that surprising that the official, supported assembly language is the focus of most books.

__________________
EEgeek.net

 

last topics

that u may learn first "asm" , sec "c" third "basic" . it will be work as a tos a coin. me also.