Serial communication between at89c51cc03 and labview

You're not so wrong, And i don't take your remarks personal at all.

But i do believe that i should be able to solve the problem, even if this would have me writing a whole new program.
The problem that i encounter lays also in the fact that i've just gotten out of school(Bachelor in electronics) and this is my first job. So i only have "basic" knowledge of serial connections.
The code itself doesn't cause a problem, it's only the link (timing) between µc and labview program. And my predecessor left here some time ago taking the flow chart with him.

So don't put all your blame on the company, i am also still finding my way around.

You're not so wrong, And i don't take your remarks personal at all.

But i do believe that i should be able to solve the problem, even if this would have me writing a whole new program.
The problem that i encounter lays also in the fact that i've just gotten out of school(Bachelor in electronics) and this is my first job. So i only have "basic" knowledge of serial connections.
The code itself doesn't cause a problem, it's only the link (timing) between µc and labview program. And my predecessor left here some time ago taking the flow chart with him.

So don't put all your blame on the company, i am also still finding my way around.

Your predecessor probably didn't have any flow charts. If he did, someone should have made sure they where electronically stored somewhere very near the source code versioning system.

It is important to have requirements, implementation (code), documentation of the implementation and test documents always in sync, so that you can follow a design change through all documents.

Just as you normally tag a source code version, you want to be able to find out exactly what version of the requirements and test specification that relates to that source code release.

A one-man-shop may ignore this, but a larger company should have a development process that helps, and also some form of control mechanism to pick up feedback and verify that what you have is really what you think that you have.

You will have to detail more of the problem. Event based programming is common. if your predecessor was more CS than EE the code may be more elaborate than you might try.
If you only have limited programming skill you have some work to do. On the plus side you have working HW and SW. Start with the data sheet look at the UART. Then find it in your code. Other then that you will have to post parts your code (IF you are allowed) and ask specific questions.

I think the contributors of this forum would be willing to go a bit further in helping you than 'normal' since you aren't a student, and have a real problem to which we can all understand (we've been there, done that, kind of thing).

All you have to do is express your problems clearly, and have done much of your ground-work prior to asking for help, and [we] will help you as much as we can.

You haven't explained what the immediate problem is (e.g. I have to expand the protocol to allow the system to do some new functions. Or, It Don't Werk), but that can come later.

Like Kurzman said, check the data-sheets, then dive into the predecessor's source code and figure out what he was doing. Reverse-engineer that "flow-chart" from the source code (that can be a pain, but you don't have a choice at this point).

Management will complain about Doing It All Over Again, but you can point out that they don't really have ANYTHING at all unless it is documented. Since you are new to embedded systems, I don't recommend jumping right in and trying to do it all over again. Learn from your predecessor as much as you can (but not the lesson of no documentation part)

But still, either management can re-invest in you doing it all over again and include the time and money to document it this time, or they can fund you to keep documenting the system until you are capable of 'improving' it (this is what I would recommend). Either way you will have plenty of documentation ahead of you.

If your company is like so many crappy companies, they'll ask you to shoe-horn in the fix/mod asap, and not worry about it (docs) until later. But that later never comes; you are busy putting fires out elsewhere in the company. And the next time a fix/mod will be needed, the same "shoe-horn it in asap and doc it later" mentality will be the expected process.

If they do that to you more than a few times, start looking for another company to invest your 'learning years' in: don't let bad practices infect your 'experience' record. (e.g. "I have five years in developing half-baked computer control systems, and can build widgets with almost no documentation at all... Can handle many concurrent and irate customer support calls too.").

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

Good advice. I doubt there was a flow chart. The last one I did was in school. It seems more of it's just micro code how hard can it be? Give it to the new guy.

Additionally Insure you have a good C Reference Book.
And the Links to the "bible"

... it is time to start learning.

1) nobody can help you with the scant information you give
2) when taking over somebody elses code the best (in my opinion only) way to figure it out is to start (re)commenting it. start somewhere (where does not really matter) and as you figure out what it does comment it in your verbiage.
3) as you progress in 2) you should be able to identify code snippets that give you troubleand present them here for resolution/comment but only when combined with your description of in/out and problem.
4) if you are 'dumb' as far as programming goes, you need put this aside and 'crawl' if you try to start running (tackle this) before you have even learned to crawl, you will break a leg.

so, in your next post please answer
a) how are YOUR programming skills
b) are you asked to do this in the belief that you are not a 'beginner'
c) how badly are 'they' pushing you.

Erik