We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Dose anybody know the purpose of doing this
void Send_CmdNo(unsigned char command){ CSX=0; RDX=1; D_CX=0; DBUS=command; WRX=0; WRX=0; WRX=0; WRX=1; CSX=1; }
why use WRX=0 3 times b4 WRX=1? wouldn't that just give you WRX=1?
by the way WRX is just
sbit WRX = P7^2;
does it mean on the I/O pin the output will send out 0 three times and 1 one time? It performs that fast?
Jay, let me repeat:
So, yes, it is only harder to debug optimized code, but in some case so hard that 'impossible' is not the wrong word to use.
Try debugging a complex one in optimized code when the customer calls your boss 3 times a day "have you got it fixed". I would say that 'hard' does not cover, but 'impossible' does.
As I stated in my prevous post I did get the 'impossible' solved, but the time it took was totally out of line.
so, let me try this one and see if we can agree:
debugging complex bugs in optimized code is impossible to do in a reasonable time
Erik
If I or one of my team released code that had as many timing problems and bugs of the type as Erik seems to have to fix then I would be very concerned.
We design and implement projects for small through to large embedded systems that frequently have to keep track of a very large number of asynchronous events. As part of the design phase, we attempt to predict as many eventualities as possible; thus reducing the chances of having the open windows for timing problems in the first place.
Timing related bugs normally find their way through gaps in the code.
A good designer should aim to eliminate those gaps in the first place.
Yes, most timing glitches are caused by invalid assumptions. Everyone with experience knows to plan ahead and design around timing issues, but the problem is that when all facts are not 100% available, assumtions must be made. You have to realize that when there are gaps in the documentation (customer requirements, protocol specifications, datasheets, RTL manuals), it is very hard not to get gaps in the code.
Because of the big problem finding and isolating them, it may be enough to have to hunt one or two every year to give them top priority, and adjust the development process in ways that helps spotting and correcting them.
As part of the design phase, we attempt to predict as many eventualities as possible; thus reducing the chances of having the open windows for timing problems in the first place. Elementary my dear Watson. Any reasonable design will be done that way.
a) but the problem is that when all facts are not 100% available, assumtions must be made. b) when stated facts are not correct. c) when stated facts are ignored.
I have had experiences where the units I work with work well with brands a, b and c and when someone buy brand d it does not work. The difference between a, b, c and d is which part of the spec they ignore.
I would dearly love to be able to state "my products will not operate with equipment that does not follow the standards" but that is a pipe dream.