Best programming Language??

If you feel comfortable writing in 'C' and things work for you then fine. If you're happier writing in assembler then that's fine too, there is no actual right or wrong way to do things. What has to be borne in mind though is that they are complimentary approaches and that each has it's pros and cons. 'C', Basic or any high level language allows for a 'black-box' approach to driving machines which means you can be more productive and also allows you to work cross-platform. Assembler, although tied to a particular machine or device which means having to learn the instructions peculiar to that machine, allows you to have a clearer understanding of the underlying hardware and gives you the opportunity to write the most efficient code. It's when problems arise that the assembler coder has the upper hand and has a better chance of locating the source of any problem. The 'C' coder has less of a chance because he/she is necessarily 'shielded' from the nuts and bolts. Even of you insisted that you only wanted to write in 'C', it would be of great benefit to at least have some understanding of assembler not only because it can help to locate sources of problems but allow you to write more efficient 'C'. It goes without saying that a full understanding of both is the best scenario!

Nigel Goodwin said:

You appear to be missing the point?, it's not about the language, it's about the underlying hardware - assembler forces you to understand the hardware, C doesn't, and it makes it difficult to program effectively without that knowledge.

Fine, you could study the hardware and understand it from a C point of view, but I would suggest that is more difficult than learning a small amount of assembler in the first place?.

You see some absolutely horrible code written in C and BASIC, simply because the writers don't have a clue about the hardware.

Click to expand...

No, I am not missing the point. C doesn't prevent you from learning the important features of the chip and it is, in many ways, easier to learn it with C because you can focus on just the specific feature rather than all the stumbling blocks of PIC architecture. You can just as easily learn PWM, capture compare, timers, ADCs and so on.

Had you said, you can (learn to) write more efficient code in asm, I would wholeheartedly agree. especially when a program overflows a bank and/or a page.

I don't think pointing to bad code is a reasonable justification. I've seen plenty of horrible assembler, too. bad programmers write bad code, not compilers. One could also point out that assembler coding is much more error prone. I taught both C and assembler at the college level and found that more people had problems writing decent assembler than any other language, by far.

And, I will continue to point out that people should really know both languages as a good engineer uses all the tool available.

I agree with phil. When I first started with microcontrollers it was a bit of a chore and confusing to program in assembly.

Then I found JAL, which is a high-level language, but lets me insert assembly wherever I want. Now I have a much better understanding for the underlying hardware. I would have been discouraged had I not accomplished things first with a high-level language (which I still use).

And, afterall, isn't this the whole point of the Basic Stamp, PICAXE, etc.?

It's probably counterproductive to try to learn the hardware AND assembly at the same time. It can be too much at once.

Mike

saiello said:

If you feel comfortable writing in 'C' and things work for you then fine. ........................... Even of you insisted that you only wanted to write in 'C', it would be of great benefit to at least have some understanding of assembler not only because it can help to locate sources of problems but allow you to write more efficient 'C'. It goes without saying that a full understanding of both is the best scenario!

Click to expand...

Hi,
i said i am intersted to learn 'C'. if you see the next sentence there in my post, you understand my mind. i do agree i am a ZERO in any language and trying to learn to have a hobby at 61+. i didn't want to discourage the person reg C but he/she should have an understanding of Assy as it is a practice to use Assy patches at places so far. Off late , due to reduction of prices and large chunks of memory embedded into controllers, one feels comfortable with HLL. ...

philba said:

No, I am not missing the point. C doesn't prevent you from learning the important features of the chip and it is, in many ways, easier to learn it with C because you can focus on just the specific feature rather than all the stumbling blocks of PIC architecture. You can just as easily learn PWM, capture compare, timers, ADCs and so on.

Click to expand...

As I've said all along, you need to understand the hardware, assembly forces this on you - C doesn't. As long as a C programmer studies and fully understands the hardware, everything is perfectly fine - but generally they don't bother (probably because of PC programming where it's not very often needed, and in fact discouraged).

It's probably as easy (if not easier?) to learn the hardware by a brief study of assembler, which only has 35 instructions (most of which you don't need to know about to understand the hardware).

The datasheets don't explain the hardware using C, and there's a generally lack of sample C code and books - a good C tutorial, giving condensed datasheets using C examples would do just as well - but does such a thing exist?.

And, I will continue to point out that people should really know both languages as a good engineer uses all the tool available.

Click to expand...

No problem, I fully agree, it's just the lack of understanding of the hardware which I see as a problem.

Well, clearly, we disagree that asm is the only way to do it. There is never just a single path to knowledge.

philba said:

Well, clearly, we disagree that asm is the only way to do it.

Click to expand...

Not really, because I've never said that! - I've said (repeatedly) that you need an understanding of the hardware to program a PIC effectively in C - and that an easy way to get this understanding is a little knowledge of assembler.

As the datasheets are in assembler, as are almost all the application notes, it makes sense to have enough assembler knowledge to convert the required hardware understanding to C. If the information was available in C, then you wouldn't need to.

Incidently I did a 'similar' thing many years ago - converting C programs to Pascal - I learnt enough C to understand how to convert the programs, something I couldn't do with zero knowledge of C.

I'm not sure your statement above jibes with this earlier one:

As I've said all along, you need to understand the hardware, assembly forces this on you - C doesn't.

Click to expand...

I think the key factor is the individual, not the language. A focused student can use either plus the datasheet to learn the features of the chip. I see nothing in the C language that makes it harder and like I said earlier, there is a clear case for it being easier in C.

philba said:

A focused student can use either plus the datasheet to learn the features of the chip.

Click to expand...

And I think we can all agree that on average, this forum tends to attract a lot of not-so-focused students. Since this entire argument stems from people making recommendations to an inexperienced individual who wanted advice on a good programming language to get started with. It's hard to disagree that ASM forces you to get familiar with the hardware, whereas in C the language doesn't force it on you, so it's up to you to take it upon yourself to learn it. You're totally right that a dedicated person should have no trouble learning the architecture while using C, but that's not for everyone.

Since we don't personally know the capability or learning habits of every single person who asks for advice on getting started programming microcontrollers, I still stick with Nigel in saying that is probably a better bet to recommend ASM before C, simply because it's more of a sure bet.

If I had a friend who I'd known for years, and I was familiar with his programming ability and knowledge of computer architecture and stuff like that, then I would be much more inclined to advise them to go straight to C... But the people who ask for this sort of advice on a daily basis can really run the gamut from high school kids with no electronics or programming experience, to college kids with a good background in programming and computer architecture, or beyond... and you have to admit, they usually don't give any good indication of their abilities.

Bah! I code my AVR's in Bascom Basic. I purchase the appropriate chips for my tasks by reviewing datasheets to understand the abilities they provide. I have as much need to understand every last detail of the chips operation as I do in understanding the complexities of pentium cpus when I code for pc. As long as the result is functioning code that does what is intended, so be it.

My priorities are easy to understand code that can be readily modified if need be (especially some time after initial programming, when the code is no longer fresh in the mind), and time investment on project construction and overall 'debugging' limits the time available for coding. Perhaps your guys projects are much more complex than mine, but I've not run into anything so far that required effeciency beyond what Basic has to offer; either in speed or size. This includes projects with lcd, i2c, spi, adc, multi channel pwm, etc. that can typically be accomplished in a very short period of time, thanks to the power of the programming functions available.

I recently finished a vector generator project for oscope display that required a lot of geometry and fractional math... I could not imagine coding this in assembly; I had the foundation of my project running within an hour. I'm not sure any benefits I would have gained in understanding the chip's hardware functioning in calculating such mathematical fuinctions would have outweighed the time and energy invested in learning and debugging them at assembly level.

Also, microcontrollers, like many other digital devices, are becoming larger and faster all the time. I expect that in the near future, coding microcontrollers in assembly will be as prevelant as assembly in pc programming is now - virtually gone.

Of course, this is simply my opinion ;-)

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.

agent420 said:

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 Apple or Atari. However, a Basic program could be run on all those, as well as a Z80 Sinclair, with only slight modification.

Click to expand...

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

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.

agent420 said:

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.

Click to expand...

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

Nigel Goodwin said:

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

Click to expand...

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.

last topics

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