Skip to main content
14 events
when toggle format what by license comment
May 2, 2013 at 16:39 comment added supercat @JohnU: I did notice it, but figured that explaining why I wrote the code as I did might be helpful. Incidentally, I was also trying to show that small tasks can fit in a small processor even if they're not optimized absolutely perfectly.
May 2, 2013 at 8:16 comment added John U @supercat - I hope you noted the smiley in my comment. Loving your work.
May 1, 2013 at 21:11 comment added RBerteig @coder543, they happen more often at an important demo than you want to believe. This kind of thinking is also required when building deeply embedded things that have no means to call for help or report an error. Or are inaccessible (think deep sea or outer space) even if an error did get noticed.
May 1, 2013 at 19:38 comment added supercat @coder543: In the absence of things like power-supply noise, not very. On the other hand, in parts without a brown-out detector, it's possible for all sorts of crazy things to happen if VDD falls to a level between the minimum operating voltage and ground, and then rises back to normal. One should generally try to ensure that any state in which the device may finds itself will revert to normal in a reasonable period of time. The two seconds or so for the watchdog to kick in may be unavoidable, but four minutes for a glitched counter to reach zero might be a bit much.
May 1, 2013 at 19:09 comment added coder543 how often do these glitches actually happen?
May 1, 2013 at 18:52 comment added supercat @JohnU: FYI, the code uses separate calls because if it used a count-to-zero counter and the count got glitched, the loop might run 255 times rather than four, while feeding the watchdog once per second. While it would be possible to guard against that by checking on each loop whether the count was in range, the code to do that ends up being more complicated than five calls and five clrwdt instructions. This isn't the most absolutely-failsafe counter arrangement possible, but some consideration is given to safety issues (e.g. the avoidance of clrwdt within a subroutine).
May 1, 2013 at 16:38 comment added John U Honestly, you could optimise your code a bit, setting a bad example to the children - 5 separate calls to wait1sec??? Wastrel! ;)
May 1, 2013 at 15:43 comment added supercat It effectively uses three bytes of memory as a 24-bit counter, which is loaded so as to loop about 333,330 times. Since the inner loop runs once every three cycles and the PIC probably runs 1,000,000 cycles/sec, that should take about a second. The first time the inner loop is reached will run 17 times. After that, count0 will be zero so subsequent times the inner loop is reached will run 256 times. I guessed at the numbers to use; if it were a real project, I would have calculated them more precisely. In any case, if memory serves, the PIC has 16 bytes of RAM; I'm using under 20%.
May 1, 2013 at 15:37 comment added coder543 alright, by the way, how does that Wait1Sec function work? looking at it, it seems to be placing an interesting set of numbers into three registers, then looping until they're zero. I guess that's the magic number that will take 1 second to decrement to zero?
May 1, 2013 at 15:36 comment added user17592 @coder543 this is a good answer, but please do not accept it so quickly. That encourages others from answering, whilst there might be even better answers out there! Just wait one or two days, so that all timezones have had a chance.
May 1, 2013 at 15:34 comment added coder543 thanks! this is almost exactly what I was looking for. Now I understand better how they're useful.
May 1, 2013 at 15:34 history edited supercat CC BY-SA 3.0
added 343 characters in body
May 1, 2013 at 15:33 vote accept coder543
May 1, 2013 at 15:37
May 1, 2013 at 15:27 history answered supercat CC BY-SA 3.0