Serial communication between at89c51cc03 and labview

I'm going to be harsh on you because I suspect that you are fixing a problem of your company's own mess. If I am wrong, I am sorry, but I
doubt it...

The vagueness of your question indicates that you are indeed clueless to the system to which you seem to be in charge. I recommend that you ask your predecessor that 'question.' Yet, I suspect that is not a do-able thing, because you came to this forum with that question---if you spoke to your predecessor, you would have a different set of questions for this forum.

Also, from the 'got tips on how to ensure a robust communication' indicates that you also don't know much about serial communications. Such an answer to that question would need far more information than your simple description provides.

Clearly, looking into your design documents (e.g. software requirements specifications, electrical interface control documents, etc) did not pan out very well. Either you or your company does not encourage the documentation effort on your systems, and are now going to pay for it by doing this reverse engineering process, or your documentation is not thorough enough. This should be a slap in the face to management to wake up to the importance of good design documentation.

I recommend that you contact a consultant who has expertise in MCU's and LabView. And, part of that consultant contract should be to document how the system works so your company's internal talent can handle the maintenance task you seem to be attempting. (I'm going to guess that the system you are working on is part of your company's Intellectual Property, and as such, you should point out to your superiors that this IP really isn't IP if your company doesn't know how it works: fix that).

Again, sorry if this is a 'rude' reply, but I smell poor management all over this question. (If you read this carefully, my response is not directed at you personally, but rather your work environment. To be clueless on 'serial communications' is not a ridicule (you might be a brain surgeon in your spare time for all I know... just not a serial communications person). The ridicule has to do with putting somebody who doesn't know it in charge of 'fixing' it: a management malfunction.

You can look for consultants by going to Keil's link...
http://www.keil.com/condb/search.asp

If I'm way off on this whole thing, please let me know.

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

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

this piece of code is not very interesting. did you not complain about timing problems? if that is still the case, please show us how the serial port is initialized, how the serial ISR looks like etc. also post other ISRs of higher/equal priority that might serve as a bottleneck in your system.

Not Just the the data Sheet

Chapter 1
www.semiconductors.philips.com/.../80C51_FAM_ARCH_1.pdf

chapter 2
www.semiconductors.philips.com/.../80C51_FAM_PROG_GUIDE_1.pdf

chapter 3
www.semiconductors.philips.com/.../80C51_FAM_HARDWARE_1.pdf

I figured it out, basicly there is a recurring time slot where data can be received by the microcontroller, the labview just keeps sending the requested string until it receives a response.

Not so mindbubling as i had expected 8-). But i want to thank you all for trying to help me out!