Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

PIC16F18856: Short software programs are less susceptibel to corruption by noise.

Status
Not open for further replies.
T

treez

Guest
Hello,
Our remote software engineer recently wrote some code for our new DALI dimmable lamp.
It’s just a simple dimmable lamp, however, due to the use of the DALI protocol, the code is enormous. When I loaded his code, and then turned the lamp on at full power, the lamp lit for several minutes and then for no reason, just turned off and stayed off. This should not have happened. :cry:

Every time it turned off, I kept recycling the power to bring it back on again, but it kept turning off, again, randomly after a few minutes or so. :sad:

Anyway, we told the software engineer what was happening and he said that his code was fine, and that the turning off must be due to our “noisy” hardware crashing his good software. :bsdetector:
Anyway, I then wrote some very very simple code for the lamp, -code that simply turned the lamp on at full power and leaves it on. With my simple code running, the lamp correctly stayed running at full power and did not turn off. :clap:
I also wrote several other similar simple programs, each one to demonstrate that all of our lamp hardware was working fine…..for example, I wrote one code which simply did PWM dimming at 50%, to prove that that would correctly dim the lamp…and it did. :clap:

We then replied back to the software engineer and informed him that our own simple code was running fine on the lamp…no errant turning off and no problems. We informed him that if our hardware was “noisy” and thereby crashing his software, then why was the “noisy” hardware not crashing our own simple software(?).
-Anyway, he replied that our simple software test programs were much shorter than his own software…and he told us that short software programs are less susceptible to noise corruption. Is this true? :???:
The microcontroller is PIC16F18856.
 

and he told us that short software programs are less susceptible to noise corruption. Is this true?
Noise is noise, if there is enough of it the program may crash no matter how big or small it is. From experience, I would say noise isn't to blame for most failures as long as good design practice has been followed.

However, I don't think Edaboard is the place to take sides over a failing product none of us have ever seen. I appreciate you can't disclose product design information but without it nobody can say whether hardware or software is to blame.

Brian.
 
  • Like
Reactions: treez

    T

    Points: 2
    Helpful Answer Positive Rating
Short program probably lacks the "sensitive feature".

Such as trying to read a critical bit of data at the
wrong (noisy) time and lacking any robustness to
input "data noise". Error trap / retry, like.
 
  • Like
Reactions: treez

    T

    Points: 2
    Helpful Answer Positive Rating
…and he told us that short software programs are less susceptible to noise corruption. Is this true? :???

No.

But I presume that your program is running in a loop; hence it is exposed to the same noise /unit time.

The software engineer is dumb; he need to learn some hardware. Without this basic knowledge, how can he interface the control circuits?

But I admit that I am fully ignorant of the DALI protocol (I presume it less dense that the artist)

Mammoth programs do rum reliably on PC and programs on PIC cannot be very large because of the memory restrictions.
 
  • Like
Reactions: treez

    T

    Points: 2
    Helpful Answer Positive Rating
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top