What is left is to resolve the angle represented by the sine and cosine averages. The quadrant is found by testing bit 7 of the high byte of the average sine and average cosine. After 2^N (right now 128) the average sine and average cosine are found by right shifting the sums. As each reading comes in, the sine and cosine value for it is added to the appropriate sum. The table was made by multiplying by 16383 and converting to signed two-byte hex. The input data is in 11.25 degree increments. This is a hobby project to try to adapt a 1970's era radio direction finder to use with a modern day mapping program. The final resolution should be a good as possible, but anything much over five degrees probably is overkill. Otherwise the next higher byte is incremented by an ADC with a cleared register and a BRCC if the still higher byte can be left unmodified. Luckily, the single byte data occurs only every 800 uS so it should get the job done.Īs it now exists, my code uses BRCC to skip adjusting the higher bytes of the sum. Yet to be written is a more complex stim file. The code seems to work at 128 measurements for all inputs 0x02 (22.5 degrees), for all inputs 0x1D (337.5 degrees), and for alternating inputs 0x02 0x1D (the latter average express 0x0000 as 0x8000). The SINs and COSs are summed in two separated additions. The input data is in the range 0x00 to 0x1F and this is converted to two byte SIN and two byte COS signed values stored in a look up table. The goal is to add up a running sum as the data comes in and then, at some point, find the average. I received no notification of the subsequent messages. The message gave me more confidence and I found I had made an error in one of the stim files I wrote. I did get a notification after the first message from theusch. I set up for a five byte sum because I haven't decided how many additions to do. Many cycles it took to generate each addend. The brings us down to 5 cycles for most additions,Ĥ cycles to fetch each addend and however Nesting the loop so that the inner loop only does 3-byteĪdditions would remove 2 cycles from most additions. The calculation above ignored the branching required for said loop. Note that it takes at least 4 cycles just to fetch 2 bytes.įor 5 bytes to be useful, I expect that this is in a large loop. To do better than 8 cycles at least one will need improving.
Note that it takes 3 cycles to note the sign of the addend On re-reading, I think OP's problem is just how to do a multibyte add.īut for addition he uses the V flag (overflow) instead of the C flag (carry). I'd have to work it out on paper, but the highlighted lines are the sign-extend?ĬodeVision: (CWD can be read as "Convert Word to Double-word I think") Avrcandies wrote: for signed numbers just extend the leading onesĪah, yes, I missed that case when I said "no fussing".
0 kommentar(er)
