hey plzz help me its urgent

The trouble is: even if he finds free (or even non-free) 'C' code, what is he going to do with it if he doesn't understand 'C'?!

To re-state the choices in a slightly different form, they are:

1. Buy it;
2. Revise the timescale to allow for the 'C' learning curve;
3. Revise the requirements and do it in Assembler.

The trouble is: even if he finds free (or even non-free) 'C' code, what is he going to do with it if he doesn't understand 'C'?!

To re-state the choices in a slightly different form, they are:

1. Buy it;
2. Revise the timescale to allow for the 'C' learning curve;
3. Revise the requirements and do it in Assembler.

But the interesting thing is still:
- you can learn to read and understand C in just days.
- you can spend years perfecting the C skills, and still not produce truly beautiful (and of course also well-working) code.

Someone who know assembler will know about the hardware that C will have to map agains, so such a person will have an easy time seeing all SFR writes when the C code initializes a serial port or a timer. And knowing assembler, it will be quite obvious what an ISR does (even if an __interrupt keyword hides the prologue/epologue the assembler code would have needed).

Since it is easy to learn to read C, it should also be easy to learn how to cut/paste existing blocks into a larger program. Problems will happens first when multiple code blocks needs to be run semi-concurrently with a limited set of processor resources available. Such things takes skill and careful design work - and that careful design work requires true knowledge of the language, and not just reading skills.

But since a large part of all embedded systems do not require hard real-time, and do not need the processor to run at very high utilization levels, most developers manages to get by even if they are lousy embedded deverlopers, or only have limited knowledge of the language they are using or the target processor. Really bad things starts to happen when the boss assumes that just because product A and B did seem to work, he must be the manager of a competent team, and then activates project C, where the complexities are high, or where the hardware is only marginally capable of fulfilling the task (remember that it takes a skilled embedded developer to make a qualified guess about how high the utilization will be of the finished product while still on the planning stages).

So in the end: If this is a critical product, then it is better to buy competence. If the company can live with the learning time (if you know n languages, then the n+1th language is normally very easy to learn, but the first one is almost always a true pain to learn) to get own developers capable of writing applications of acceptable quality and capacity, then it is better to say that you need more time, and then start a very accelerated learning cycle.

In neither case is "give me code" a working solution. Working code is only working if you know exactly what it does, and more importantly: why it does it. That requires that you can read the language, and that you can translate from the source code and back into the datasheets and verify line-by-line exactly what the code does, and how the code matches the datasheet requirements.

I certainly don't think that the OP will be able to learn C, get Blinky running and incorporate his "internet code" in time for an early Feb showing. Hence my "expect it to fail" comment.

Who has ever used code from the internet without knowing how it does what it does? Oh, that's right: students (and the guy that did my TV cable box).

Andy's re-list is apt, while Per's is the safest course of action: "If this is a critical product, then it is better to buy competence."

"...post the most f%@!#d up posts..."
So, Per opened a can of sardines on "Master Zeusti"? -- Much enjoyed.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

At the risk of having this being taken the wrong way, I feel this has to be said:

Is there a way for you people to make some of these comments sticky on this forum.

I come here occasionally to see what's been occuring and so frequently see almost the same comments being made by the same people.

Only if it's basically similar to the other n languages.

I get the impression that Assembler is the OP's only language; moving to a high-level language - any HLL - is quite a large step.
But, thereafter, learning another HLL will be much easier...

As you say, knowing assembler will be some help - but not as much as knowing another HLL.

I don't consider assembler a programming language. To me, it is just a set of mnemonics.

So, in this case C is most probably the first language. And the first language normally takes a lot of time to learn and understand. Especially pointers, arrays, and the importance of evaluation order.

When you do know n languages, where n is starting to get big, then even "strange" languages will have pieces that are similar with the already known languages. The first functional language will feel strange, but the second or third will just be different writings of known concepts.

In this case, the big value with knowing assembler is that it helps with pointers, and it helps with understanding what SFR are and what makes a processor tick. Knowledge of assembler also allows the user to realize why a trivial C source line may expand into a large number of assembler instructions, or into function calls to helper functions. It is so easy to think that a source code line that looks trivial really is trivial for the processor. There should be a law that every programmer has to implement a division routine in assembler - especially since all that code represents a single little forward slash character in the HLL.

Trevor: Yes, sticky threads would be nice. But we are just end users, so we would not be allowed to edit them, or make them sticky.

Keil already have their own way to handle common questions. They have a number of FAQ pages that contains links to one or more forum threads that does cover the specific question. But it requires the users to use the search function, and a lot of Keil visitors have a policy that search engines must not be used.

Which, of course, also defeats the object of "Sticky" threads...

:-(

One thing that would be useful, though, is an easy way to get a link to an individual post - rather than just entire threads...

uk.youtube.com/watch