Serial communication between at89c51cc03 and labview

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

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