Hello,
I'm analyzing a labview programma that enables a at89c51cc03 microcontroller to communicate with a labview programm running on a pc trouhg serial communication (uart based). I believe my predecessor used some sort of event based communication. Does anny of you happen to have experience with this type of programming and got tips on how to ensure a robust communication? I am programming in C51
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.
View all questions in Keil forum