I’ve been getting lots of good ideas from the smart guys over at Parallax. They are throwing out a variety of methods and ways I can get this job done. I will say that I’m a little overwhelmed at the pure number of ways to attack the problem. I’m glad there are multiple ways, but this allows me to instill doubt in the current method, and leave an easy way out. It’s easy to say, “oh this isn’t working, forget about debugging it, and just switch methods”
I now have at least 5 different versions of code written by different people, but which none of them currently work. I then, of course, have my own version of code which is the only version to have yet produced any valid data whatsoever. And so I’m partial to my own code. It’s easy, simply, straight forward……..and its not in assembly. Which I will say, however, that I’m getting much better at reading it since all these versions of code are in assembly.
Some of the different methods presented are:
Two interrupt sources:
mine (in SX/B): the ISR handles both the edge detection (via wkpnd_b) and the timeout condition. The main code handles PC communication solely. All shifting happens in the ISR. Edge triggers the ISR.
I actually have several different versions that handle it all sorts of ways, but the only version to produce any results is this one.
Peter’s: the ISR handles both edge detection (via RTCC values) and the timeout condition. All shifting done in the ISR. Main handles PC communications only. Edge triggers the ISR.
His version is very similar to mine in overall layout, although I’m sure his is much better done. This is reassuring though, because this was the method I ended up choosing — he determines an edge differently from mine, but the overall idea is the same.
Michael’s: the ISR is triggered both by timeout and by edge detection. ISR handles the shifter. Main handles the PC communication only.
One Interrupt source:
Guenther’s: ISR triggered only by RTCC rollover. The ISR keeps track of the number of interrupts that have occurred between edges. ISR handles PC comm. Main polls wkpnd_b for an edge and does the shifting. Similar method suggested by Jim P.
Brainstorming indeed. I just have to figure out what’s going to be the best method.
I’d be thrilled to debug my code and get it working. I have to sit down and list the possible things that could be going wrong, and design tests for them to rule them out. Since other’s code is similar to mine, and the fact that it is producing some data is encouraging. It tells me I’m not entirely on the wrong track.
Some questions on my code might be:
1. Are we missing edges because we spend too much time processing a high, which is a very common and regular task. Edges are less frequent, but more important. Losing an edge causes us to lose at least one ‘0’, and potentially up to three ‘0’s — because the SX will think we’re idle when we are not.
2. Is our rollover not happening at the right time? For instance, is a rollover happening too close to an edge, which further complicates problem one? It complicates it because if it samples too close to the edge, then we’re in the ISR during an edge event, and so the interrupt doesn’t re-fire. And then, we only detect the edge has occurred as result of entering the interrupt from a rollover which is BAD BAD BAD because we should be storing a ‘0’ at that point, not an edge. We should never sample an edge or a low during a “0”-cell.
3. Does the PC perchance get overwhelmed with the flow of data, and because of multitasking, etc start dropping bytes? My code currently wouldn’t notice this —- and this wouldn’t effect new data…
I guess what I really need to do is start writing more checks into my code that will generate a breakpoint if one of these bad things happen. Run the real-time debugger, and see if it breaks someplace.
It all comes down to timing, and this is why I have pjv really reviewing my code for timing issues, etc.