Yeah I am up and running getting these numbers I'm quite surprised how easy it was to get some numbers on the screen and have them change via RC... Neat o..
Yes the servo wires finally arrived not really sure who called it in a previous post but they are quite thin gauge for the copper inside them. anyway moving on
I'll look into finding the sticky on reading the inputs in the order the receiver pumps them out.
One suggestion was I had sent AcidTech a PM about possibly introducing a newer version of pulsin that was specifically designed to read RC inputs, but then I was going to modify the pulsin command to set the delay to around a little bit longer then the pulse takes to send the widest signal possible to a servo. .5 to 1.5ms wide I believe it was.
You can also do some additional expermentation of how to use the processor. For example if your receiver always generates the pulses in the order 1, 2, 3, 4, and to make it work well you find that the order Zenta used works best for you (1, 3, 2, 4), you know that after you do the first Pulsein, you have a certain amount of time before the 3 pulse will start. So you could insert some processing code in between your pulsin commands to use a certain percentage of that time. Obviously you want to leave enough time to be in the pulsin 3 command in time. Likewise between 3 and 2 and again 2 and 4. You will most likely lots more time between 3 and 2... I hope this makes sense.
Yes this makes sense.
The other approach as Eddie mentioned was that I used interrupt processing to handle the inputs. Yes I used the WKP lines for this. You first set it up to interrupt on leading edge, grab a timer count, then set to interrupts on trailing edge get the timer count, subtract and save away the differences. This worked OK. I was processing 6 channels of data this way. The timer value may not be as accurate here as you had to wait for interrupt processing code to happen to get the timer tick values, which may be off slightly depending on chich instruction was happening when the interrupt occurred... Although I found it close enough. If I were only interested in 4 signals, I might be tempted to use the input capture capabilities of WTIMER as it is setup to do this for 4 channels (This corresponds to IO pins 9-12 on the BAP). The plus of using interrupts is that the code is not spinning waiting for something. When the signal comes, you simply grab the values maybe do a bit of calculations and then return back to your main code. Yes this does steal cycles from your main process. The downside to this is there is someoverhead in interrupts (interrupt start, register save and restore, interrupt return). This can also cause your timing loops problems. For example my MPulsin command counts exactly how many instructions happened between IO pin transitions to know the timings, which is very accurate. Now suppose that while counting an interrupt happens that eats 100 cycles, well my calculated vaues is now off by that. This is why there have been several threads on why high speed serouts have problems when you have interrupts being processed.
I believe this is a bit beyond me at this point seems like too much to do something so simple "to be slightly blunt about it" comments welcome.
The reason it takes the 20ms is that you have to wait until the actual pin you are sampling goes from a low state to a high state, at this point the signal will stay high for between 1ms and 2ms. This actual cycle can take up to 20ms. The actual pulsin knows nothing about the servo stuff nor 20ms. By default it will timeout after 65535us. You can increase the timeout by multiples of 65535. The reason for this number is the code probably simply iterrates waiting for the transisition states and adds the number of cycles that iterration took to a 16 bit register and detected when that variable overflows...
Yes from what I understand about that is each channel blasts out 20ms worth of data when only .5-1.5ms of that is used "why they designed it that way .... maybe signals arnt far enough apart and RF interference ?? not sure" My idea was to modify the pulsin command to have a lower timeout value perhaps 2 ish micro seconds and then read the next channel... But i believe i see a flaw in this method as it would timeout on channel 2 if the receiver was still sending the remaining 17.5ms of data on channel 1, the channel 2 would be blank for quite some time and that 2nd pulsin command reading channel 2 would be zero.
as for the overflow I do notice when i debug and im watching variables there is a time when i see no data like it has overflowed and is internally reset this happens in about 5-10 seconds then its back to spitting out numbers in the debug window ... is this overflow? of the 16bit register? would the solution to be reset this register after so many pulsin reads? or is what im seeing some other problem.
so Looking at your fancy oscope logger the only way I could see my modified pulsin command to work with shortened timeout values would be to make sure the reading of my 4 pulsin commands somehow was able to be started at the instant the receiver starts outputting whichever channel spits data out first to keep all the shortened pulsinreads synced 'I hope this makes sense"
as I said previously you wouldn't want to read a channel halfway into its output or you would be getting an incorrect value..
So all and all it seem's like I have a couple options here
1) use my code on a 2nd botboard and deal with it for faster reads using much simpler code and not have to worry about which order the servo signals are sent at
2) use kurtes code 'I don't understand this at all" use the materials I already have and get it working "I'm not sure if someone has already done this and if so id love to see the source so i can try it"
3) use some other method which I still would like to try converting the pwm values into voltage or some other form of digital circuit and use something like adin function for reading the values and doing some internal math converting these numbers as for pwm conversion I really don't have a clue as what I could convert it to..
but I was thinking about using something like converting the pwm signal to voltage and using a transistor then using the 5volt off the bb2 to get a wider voltage range... I can already see problems with this how the lower the input voltage your values start degrading "your battery starts draining in your phoenix"... so don't know about this.
4) use some magic circuit no one knows about to convert this all for you to some other type of signal
5) I would not mind using an additional bb2 to loop though my simple code and have a serial link sending the other bb2 values...I do not know how much better this idea would then using kurte's assembly and 1 bb2 would having the master bb2 read data over a serial pin vs reading data on the ps2 controller take the same amount of time?
In Xan's code I do see delays when raising the body and lowering it changing gait's exct but I do not see delays when moving the analog sticks forward.
Kurte yes I find everything you say useful do I understand it all?? well about 80% of the theory I just don't know as much as you about the proper way to do things and optimizing it, seems like with 30mhz processor speed you should be able to get away with lots of slop..