C Programming

Good idea,

I will try that.

Thanks for the suggestion, as I was getting frustrated and could not think of anything.

Del, GA.

I was once in an IBM Systems training class in Frankfurt many years ago.

It was held in German, but all the English words used by everyone worldwide to describe parts and functions since time began in the computer world, had been "converted" into High German. 10 feet long words!!!

It was very confusing, half the "new" German words I simply did not understand at all, some you could guess at.

At the midday lunch break, I said to the rest of the class, all German nationals, that I was walking out of the class as it made no sense to me whatsoever....

THE WHOLE CLASS STOOD AS ONE AND SAID THEY DID NOT UNDERSTAND A WORD EITHER!!

I said to them, why didn't you say something before?!!!

The reply was, that I (me!) "seemed" to be understanding it and they did not want to look stupid!!! DUUUUHHHHHH!!

I got my Boss in and we discussed the problems and the training company got thrown out.....

Ya Hochdeutsch and their double, triple quintuple compound words. Was one of the hardest parts for me learning German. :-P

This is going of the dusty trail a bit.

But wasn't there a push about 10 years ago to change all the standard technical language into... French?

I'm sure it was the French that may have made the push.

It was basically for electronics or control? It was in a tech journal.

And THAT is why the act of walking into a place like you own it and ordering people around (when you have no business or authority do do so) is known as the Bavarian Fire Drill.

I hate to pick on my bretheren back in the homeland, but it's a simple fact, more visible in cultures with a hierarchal society but always there even in eglatarian societies: If you go around acting like you're in charge, people will assume that you are.

Here the person 'in charge' was the instructor, and the students were reluctant to challenge his authority as teacher by asking what the foch his Sesquipedalian Loquaciousness was supposed to mean.

"If you go around acting like you're in charge, people will assume that you are."

That's similar to people in an elevator. At least 35 years ago....

the higher up on the hierarchal ladder will look confident, while the surfs will look submissive.

C can be very frustrating - but IMHO it's worth sticking to it 'til you get the hang. I used to use C exclusively way back - but I now use VB.net. Very few days go by before I think "Damn, why can't I just <whatever>? If only I was using C, this would be 2 lines of code instead of 50!"

Stephen Prata's C Primer Plus.

You'll find it at Amazon for $0.01 + $3.99 shipping. Like new condition! I bought it hoping that somebody read it for me, but, as I said, it is in "like new condition". Darn, I must read it!

I took 'C' programming (night classes, 24 years ago) when I was about 30, (a time that C++ was coming around, with OOPs) the problem I had was the COBOL programmer's in the class that were 55+ (Fossils) that give me trouble.

They loved talking about themselves and how great they are, and won't hesitate to crucify anyone that challenged them.

'C' experience was good, I actually purchase a complier (Borland). and wrote a few programs for work. (of which after 25 years, they still are using variations of the source code) I haven't found the need to code for a long time.... at least to any extend that amounts to anything.

yep, I agree, those pioneer programmers didn't know what they were doing....

Real programmers (like the "pioneers") used:

1401 Symbolic Programming System

http://en.wikipedia.org/wiki/MACRO-11

http://en.wikipedia.org/wiki/Binary_code

you mean assembly language.

Sure - pick one!

Every machine had one, some were known with the "brand" of computer manufacturer, some were invented on the fly for special purpose applications. Today that's called an ASIC I believe.

You should have studied on your own for a while before starting the class, that way you get more out of the time spent in class....Your best hope as I see it is private tutoring....and total immersion...

http://www.cprogramming.com/how_to_learn_anything.html

that's what I did.

And that's why I gave you a GA... ^{because I may have been a little bias}

Reality is the same for everybody, it's only its recognition that varies....

Exactly!

For me, MY most *successful* learning technique was to code-up a "packed" FFT program, ie: something *useful* to me. This became my personal "project" with each new programming language that I learned (almost chronologically):

1) in FORTRAN

2) in BASIC

3) in 8080/Z80 Assembler

4) in Ada

5) in Pascal

6) in C

7) in C++

I once wrote a 256 point FFT to run on an 8085 CPU (which basically used the 8080 instruction set). The first step was to write code to multiply two numbers and hard code tables for sin/cos look up using only the simple instruction set of the CPU.

It took about 3 seconds to run at a screaming clock rate of 3 Mhz.

It's so much easier to write in C code!

"... powerful enough ..."

Yes, it certainly is.

In K&R's (Kernigan & Richie's) original little 9-mm-thick tutorial, 'The C Programming Language,' the language definition itself is located in an appendix in the back of the book.

Some may think that C's limited number of keywords and constructs implies a lack of power when, in fact, it is C's lack of constraints. You can do anything you want in C. Anything at all. This is both a blessing and a curse.

Even for seasoned programmers, it is easier to hang yourself in C than it is to breathe. Still, it is one of my favorite languages, second only to Python.

You must mean C++? Nobody uses straight C any more. I feel your pain and learning a language as subtle as C is tough going. Everything is focused in object oriented today and C is used only in a few tight niches - and even then it's always C++. Ask yourself what you're really going to do. If you want to code there is a vastly larger market for Java! Still OO of course. Not as low level as C. Might be easier get, and that doesn't mean it's easy!

I am learning C to program motor controller.

So it is not a question of easy access.

By the way, does C have an alternate for motor controller programming?

Any suggestions will be appreciated.

Ok makes sense. Machine & process control among C's niches. Try to remember you don't always have to know everything about a language to get real work done with it. Good luck!

There are all kinds of languages that can be used for motor control, but control at what level? Hard against the metal, at the register level? Higher level, through an API (Application Programer/ing Interface? Higher yet, application-specific languages executing on a motion-controller module/board/PLC?

The problem with answering your question is that it encompasses too large a swath to be answered in any but the most general terms. Quite understandable if you're new to the field, so no worries. You've simply so many more choices than you might have imagined.

Really, the languages and methods used to 'talk to' motors are probably as numerous as the people using them to write motor-control programs! Perhaps we should narrow your question's domain somewhat?

I remember when Forth was first available for a simple ZX-80 and 81 computers, I managed to control a telescope for a friend's son with it, so that the star/planet being observed stayed dead center in the scopes field of vision. A small wonder in those days....

I have absolutely no recollection of the language at all nowadays!! NOTHING!! Except the name!!

I had to have both a hardware interface and a memory module on that awful connector at the back.....I also had to interface a proper keyboard as the original was really "iffey".....if I remember correctly....

Those were the days!!!

FORTH

So you can learn by working on your problem. It's much easier to learn when you have a practical purpose in mind instead of just cramming facts.

Write out what you want the program to do. Break it up into small pieces if possible. And "printf" is your friend. Run a little piece of the program at a time and print out one or more variables and verify that they are what you expect.

It is a mistake to write a huge amount of code and expect it to run correctly the first time. Write a little, test it and make sure it works the way you want. If you have too much untested code at one time, it is sometimes hard to figure out why it isn't working the way you expect.

Sometimes it helps to simplify. If you can solve a simpler version of what you are working on (e.g. fewer inputs and outputs), you can see that it is doing the right thing, and then expand it back to the original problem.

Although I "code" far less than I used to, all of your comments are fully valid and if taken onboard by other coders here, will help them!!

Many thanks.

I remember that even when a program is doing everything as it should, adding all the bells and whistles to prevent a user putting in wrong values as well as making it "look" better, would often more than double the physical size of the program.....as well as being as much "work" to get it just right!!

That is exactly what FORTH was designed to do. You create little programs called "words," then you make bigger words out of those, and finally one big word that is your program.

Whatever the language:Top down design, bottom up coding.

In forth, you build on a system model that is processor independent. Start with a small set of assembly routines that set up the model, then you make calls to these routines with pointers defined in higher level as 'words' defined in 'definitions' that create a dictionary that you use to build a program.

The power of forth lies in it extensibility, and immediate execution by the interpreter of definitions for testing. Its weakness is the absolute control given to the programmer.

That's what I just said!

Only true for writing computer programs: industrial applications use C because it is deterministic. Java is a higher level language which is used for ease but it has a much higher overhead and uses significantly more memory.

Try using JAVA for real time signal processing...

What happened to the rest of my data...? Oh, JAVA decided to do garbage collecting!

Which is why C is the only choice for automotive applications.

: garbage! C rot rot rot compost ;

I beg to differ. C is still used a fair amount at the hardware level. It doesn't have the code overhead of the higher languages. So it fits better on smaller devices. Yes, makes bigger code than assembly but assembly is very device specific.

You are correct at the system level though. C is being superceded by more efficient languages.

Assuming we are talking about motor control or anything designed ad hoc the bottom line is ...
At hardware level you are using assembler, and that's where all these fancy "high level" languages fall down.
At the end of the day, if you've designed the hardware you have to write the various drivers. Or pore over generic drivers written for some development board which almost work as you want and have virtually no documentation or have endless layers, names labels, functions etc just to toggle a bit.

It's like driving your car car by sitting in the back seat and using two broomsticks to reach the controls.

Del

http://www.danielsen.com/jokes/objecttoaster.txtOnce upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob, and a lever. "What do you think this is?" One advisor, an Electrical Engineer, answered first. "It is a toaster," he said. The king asked, "How would you design an embedded computer for it?" The advisor: "Using a four-bit microcontroller, I would write a simple program that reads the darkness knob and quantifies its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast. Come back next week, and I'll show you a working prototype." The second advisor, a software developer, immediately recognized the danger of such short-sighted thinking. He said, "Toasters don't just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities. They will need a breakfast food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don't look to the future, we will have to completely redesign the toaster in just a few years." "With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork, and poultry. The specialization process should be repeated with grains divided into toast, muffins, pancakes, and waffles; pork divided into sausage, links, and bacon; and poultry divided into scrambled eggs, hard- boiled eggs, poached eggs, fried eggs, and various omelette classes." "The ham and cheese omelette class is worth special attention because it must inherit characteristics from the pork, dairy, and poultry classes. Thus, we see that the problem cannot be properly solved without multiple inheritance. At run time, the program must create the proper object and send a message to the object that says, 'Cook yourself.' The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs." "Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don't want the eggs to get cold while the bacon is frying, so concurrent processing is required, too." "We must not forget the user interface. The lever that lowers the food lacks versatility, and the darkness knob is confusing. Users won't buy the product unless it has a user-friendly, graphical interface. When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it, and the message 'Booting UNIX v.8.3' appears on the screen. (UNIX 8.3 should be out by the time the product gets to the market.) Users can pull down a menu and click on the foods they want to cook." "Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform for the implementation phase. An Intel Pentium with 48MB of memory, a 1.2GB hard disk, and a SVGA monitor should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built-in GUI, writing the program will be a snap." The king wisely had the software developer beheaded, and they all lived happily ever after.

Made more readable (more similar to the original text!):-

http://www.danielsen.com/jokes/objecttoaster.txt

Once upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob, and a lever. "What do you think this is?"

One advisor, an Electrical Engineer, answered first. "It is a toaster," he said.

The king asked, "How would you design an embedded computer for it?"

The advisor: "Using a four-bit microcontroller, I would write a simple program that reads the darkness knob and quantifies its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast.

Come back next week, and I'll show you a working prototype."

The second advisor, a software developer, immediately recognized the danger of such short-sighted thinking. He said, "Toasters don't just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities.

They will need a breakfast food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don't look to the future, we will have to completely redesign the toaster in just a few years." "With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork, and poultry.

The specialization process should be repeated with grains divided into toast, muffins, pancakes, and waffles; pork divided into sausage, links, and bacon; and poultry divided into scrambled eggs, hard- boiled eggs, poached eggs, fried eggs, and various omelette classes." "The ham and cheese omelette class is worth special attention because it must inherit characteristics from the pork, dairy, and poultry classes. Thus, we see that the problem cannot be properly solved without multiple inheritance.

At run time, the program must create the proper object and send a message to the object that says, 'Cook yourself.' The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs."

"Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don't want the eggs to get cold while the bacon is frying, so concurrent processing is required, too."

"We must not forget the user interface. The lever that lowers the food lacks versatility, and the darkness knob is confusing. Users won't buy the product unless it has a user-friendly, graphical interface. When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it, and the message 'Booting UNIX v.8.3' appears on the screen. (UNIX 8.3 should be out by the time the product gets to the market.)

Users can pull down a menu and click on the foods they want to cook." "Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform for the implementation phase. An Intel Pentium with 48MB of memory, a 1.2GB hard disk, and a SVGA monitor should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built-in GUI, writing the program will be a snap."

The king wisely had the software developer beheaded, and they all lived happily ever after.

and here is an example of the difference of style and how it affects readability

Sorry about the formatting. I was in a hurry and didn't notice "cut and paste" didn't pick up the carriage returns / line feeds.

It makes a good example of how some programmers write code that is hard to read and how a few simple changes improve on that.

The story is a good example of how bloated most operating systems and programs have become.

'C' does start out with a steep learning curve. I started by reading the book "The C Programming Language" by Kernighan and Ritchie, (hope my spelling is correct here). Once you get into pointers, things seem to 'snap' into place with the understanding of this language. I would recommend trying to stay with class until then, it will come to you with just a little perseverance.

If your professor gets a little haughty and push comes to shove, perhaps remind the dear professor that there was a time when he was in your shoes, learning the language for the first time and, given his teaching style, ask him what are the chances that he would have preferred a different professor than himself to teach him? If he's impatient and haughty, I'd say the chances are pretty good.

Sometimes people forget their roots and so lose their way. Everybody was a 'dummy' once - including your professor. It may be helpful to remind him of that - and yourself that you'd mastered a great many things already and long before he was even a twinkle in his daddy's eye.

Here's a free online tutorial you might like. It's pretty straight forward...

http://www.tutorialspoint.com/cprogramming/cprogramming_tutorial.pdf

There are a gazillion good tutorials - enought that you can find one that speaks to you.

The K&R book is a good place to look when the tutorials are starting to make sense to solidify your new knowlege.

To flex your new knowlege I suggest the absolute best place to turn is to read other peoples code. The web is full or real code doing just about anything you can image if you care to search for it. This will show you how real people use the languge to do real things like you want to do. Don't assumed that if you can't read it that you are the problem - some people write crappy code.

Reading other people's code is very much a mixed bag and discouraged for a biginner.

It's worse than trying to learn how to be a good writer by reading everything from Shakespeare to porn.

The reason is is worse is that it is not possible as a beginner to recognize good code writing practices from bad and there are far more badly written code examples on the internet than good.

Programming requires both an understanding of good architecture (not to be confused with style) as it does a mastery of the language itself.

It helps if they have a good habits of coding structure. But at times this can take time to cypher.

I spent 20+ years coding and leading teams to develop embedded software for aviation DO-178B level B and Level A.

Structure is mandatory. Hard to imagine it any other way, but I think if I were to ever read the code that's inside my Kenwood car radio I would get the worst case of gas. ;-)

Not too hard,

I consider myself a novice... and never really considered myself a true programming, even though I would trouble shoot code through the night. (A lot of the trouble I had, was not the syntax, but actually appearance and had to do with my structure,.... or lack of.)

When I first started programing, my major required programming classes but the classroom instruction was very basic. And even though structure should have been the foundation, I must have been sick that day when they covered it.

Because the structure of my programing was horrid. Mostly because I had to learn on my own, and only then did I learn the real value of this. (Also because I was learning and doing concurrently, my grasp of the syntax was also weak)

A company where I worked for, I did a rather involved program on my own. (Only because I was told it wasn't needed) My response was, no its not needed today, but it will be tomorrow. Still I was told not to, but did it anyways on my own time.

I left that company and 7 years later I was called in (interview) when I was looking for a contracting position.

They showed me what I was going to be doing me, and showed me their source code and asked if I understood it.

I did, it was beautifully structure (someone rewrote it my code and structed it beautifully) but I recognized it as mine code I wrote, because my sub routines (POW) acronym for Prisoner Of Work or hop-a-long, such as that. Some routines even ridiculed crappy co-workers and bosses...., (even those subs stayed the same).

I told them of course I do, I wrote the base code. Of which they were surprised and was not aware of it, until I started to explain the routines to them with not so much as a glance.

I don't program anymore.... only because it keeps me up at night.

Granted that C is hard to read, and bad code even more so.

The thing here is learning how to do things in C. Reading other peoples code and working through what it might mean is a way to reinforce what the language is all about.

Every languge has things you do to use the features of the language; what I do in Basic is very different than what I do in C; there is absolutly nothing in basic that prepares you to deal with pointers. That said - once you learn how to do things with pointers you miss them when they are not available.

C is just assembly languge with the rough edges knocked off; learning either one helps you learn the other. Since the CPU "speaks" assembly languge embedded programming is likely to work better with one or the other for a long time to come.

I did not say C is hard to read. I said that for a beginner, picking up other people's code and expecting to use it as good examples of C programming is little different than picking up a used condom off the street - you just never know where its been.

This is why we have instructors, so we do not start down the path of bad habits. Unless you know what is good and bad you have no way to discriminate between them.

So I fundamentally disagree that reading other's code is necessarily a good way to reinforce good practices because the beginner is clueless. Once you understand the fundamentals it may be another story.

C is not quite assembly with the rough edges knocked off. It is still an abstraction of machine code, but that abstraction makes it portable, whereas assembly is not.

The only thing that learning assembly code will translate to other languages is learning about structured programming. That assumes that structure is taught as part of any course. However, you don't need assembly to learn about structure. Any language will serve for that. The alternative is known as spaghetti code.

I agree that C, and to a lessor extent - assembly, will be the backbone of embedded programming. However, assembly is rapidly becoming redundant in most applications due to the huge speed of modern microcontrollers and the low cost of memory.

20 years ago that was a different story, but now C++ and operating systems are finding their way into embedded applications where they were unthinkable before.

Hey there, I have learned C/C++ in the past on my own, but right now I am learning Java in school. The professor makes absolutely no sense. He is very disorderly in his lectures, and jumps from window to window as he tries to explain things. But there are some very good text books for learning programming languages. I was about a month behind on getting through the homework, but I opened up the text book, which had very clear examples, and in a week I had caught up with the rest of the class.

I have also heard from others that programming is one subject that is best learned on your own. You cannot survive programming if their are holes in your learning, you have to study it thoroughly on your own.

I can share your pain, I learned to touch type at 50 and started programming in basic at about the same age, probably a little younger. My motivation to type was to develop speed to input to a computer. I have managed to extend this particular life to the point that I will be 76 this month.

I am still fighting these pesky languages, this advise probably won't be of much use to you, but I found that any language that needed a compiler was usually so committed to structure and for lack of a better term "purity" that they can't be approached with something as simplistic as common sense.

I personally found that I had to approach the higher level languages by learning the more forgiving languages like HTML, Javascript, PHP etc. Not only are these forgiving there is enough information on the internet that you can find an explanation that you can understand on the interne, and if the first one doesn't make it clear there are at least 20 more to choose from and you can understand one of them.

Even some of the "tight ass" languages have better explanations on the internet than you will get on campus.

include, void and main to you.

Good luck

You have got to the root of the matter.

I was trying to search for some logic in the structure of the program instructions and failing which , was getting frustrated.

But, now i have learned to leave common sense behind and rote the syntax for each command(initially) and repetitively using the commands by practicing a lot is helping.

Its working.I am writing small codes, successfully.

Thanks all, for all your insights and sharing your experiences.

Much kudos on the typing - 76 wpm is astonomic !

Leg-pulling aside, I am peeked to ask how you learned to type. Even after many years of such stuff as Mavis Beacon, I just can not do it. Whilst doing a course some years back, the tutor got so frustrated he took out a marker pen and wrote on each of my fingers which key it was to be used for.

I'd look into my keyboard mayhem more, but other stuff troubles me. Several personal friends have said that they now e-mail, not just because it's easier, because they have lost the art of handscript. Joyous news to me, because my handwriting is worser than my spelung.

Every try I've ever made at touch-typing has flunked, and hardly for lack of trying. To make me double-stupid, I can shut my eyes and know where every single key is . Fingers and <whatever it may be> just will not communicate.

Well, you just have to get over the fact that typing and scotch don't mix.

You're darn right - Vodka is much better !

The typing was a real chore, I went the online "Mavis Bacon" route, I don't remember the program. I do remember that I put an unbelievable amount of hours into it. At my peak I could do 40/min. on a computer, back then a lot of it was on a typewriter (the most unforgiving device in existence) where my speed faltered to about 20/min.

It was probably one of the better usages of my time for the results obtained. I now time myself by how long it takes before my fingers start to cramp up. You got to love old age.