Yes, I have not updated the code in a little while.
Kurt
Thanks 
I’m not sure if you looked at zenta’s rc version of the ps2 code and I have been learning it and playing with it quite a bit… planning on snagging a gyro for some experimentation shortly…
This assembly is quite a bit over my head but seems like it will drastically help speed up the rc read code,
Is it possible for me to simply paste in just the assembly code without the rest of the application… it appears that awPulsesIn var word(16) is the variable that stores the 900ish to 2200ish decimal value in the array… I can’t find this anywhere inside the assembly?? unless I’m missing something here
Can this variable be changed to store into some other name?
It kinda looks like I can get away with setting all 7 pins as input and just using awPulsesIn , it looks like the other things you have added inside are some features that allow transmitter loss and an error control output bit…
Fpulsechange does this simply show a bit when it has new data?
what did the i byte do?
will be interesting to poke around with this.
I’ll have to toss this into a test program and play with it, hopefully this will make the RC phoenix walk much smoother like the ps2 code, I have a feeling the pulsin values are causing hiccups in the gait movement…but it could possibly be my additions to it “I always try and code simple but i might have made small correctable mistakes”
you have that logic probe… do you have any way of testing this rc code and trying to determine if the atom pro is close to max cpu usage?
anyway here is that RC code Ive been editing around with
pastebin.com/f5a5a916c
I wasn’t sure if you had a phoenix or not, or if you had a way of testing it all … anyway… talk to you laters.
–Aaron
Yes, I played around earlier with Zenta’s RC code, I used it with Xan’s phoenix code hosted on a CHR-3 hex.
U found the assembly language on the H8 pretty easy to learn, at least as to be able to read it. But I have done a few assembly languages in the past. All of the information is contained in the H83694.pdf file that you can open from the help menu of the BAP’s IDE.
Appendix A shows the instruction list and talks about the different registers and the like. There is also some information about inline assembly in the post: lynxmotion.net/viewtopic.php?t=3347
There are 8 32 bit registers (er0-er7), these registers can be accessed 16 bits at a time by e0-7 and r0-7 (r0 is the low 16 bits of er0 and e0 is the high 16 bits of er0). R0-7 can be access by 8 bits at a time (r0l is the low 8 bits of r0 and r0h is the high 8 bits of r0). There are no 8 bit access for the e0-e7 register words.
The inline assembly allows you to access basic variables. However basic automatically uppercases the variable names and the language itself is not case sensitive, however the assembly is!. So to access a variable that in basic is wPulseMask, in assembly you use WPULSEMASK. In assembly putting an @ infront of a variable means to get/put the contents into the location that is pointed to by the address. so for example:
mov.w @WPULSEMASK, r1Says to move a word (16 bits) from what is stored in the variable named WPULSEMASK into the 16 bit register r1.
If you look at the lable _P17_IO_WENT_HIGH:
you will see:
[code]_P17_IO_WENT_HIGH:
xor.w r2,r2 ;(*2)
mov.w #1, r4 ;(*4)
mov.l #AWPULSESIN,er3 ;(*6)
_P17_WHICH_BIT_LOOP:
shlr.w r0 ;(@2)
bcs _P17_WHICH_BIT_LOOP_DONE:8 ;(@4)
shll.w r4 ;(@2) - Set up our mask
inc.l #2, er3 ;(@2) - point to the next place in the array.
add.w #18,r2 ;(@4) - we do 18 clocks for each pass through this loop
bra _P17_WHICH_BIT_LOOP:8 ;(@4)
_P17_WHICH_BIT_LOOP_DONE:
[/code]
This code moves the address of this array into the 32 bit register er3, it then figures out which of the bits went high and while looping though to figure out which bit, it increments er3 by 2 as our time values are 16 bits in the array. So after this loop the register er3 points to where we want the value stored. This is probably the most complicated part of this code. The actual time is stored later on in the code:
; aPulses(iPin) = iPinLoopCnt ; convert loop count to pulse width...
mov.w r2,@er3 ; Save away the valueWhere we store the 16 value in register r2, which is our computed time indirectly into er3 which contains the address of the array element within awPulses. Oops I see I did not change the variable name in my comment there…
Yes you can change variable names, but you need to change it both in basic as well as in the assembly. Old habits die hard. I used to work where we had coding conventions, which included something about variable names. So form the variable nameawPulsesIn, I know that it is an array(a) of words(w).
fPulseChanged is simply something in the basic part of the program that after I went through and received a new set of things, I decide if there was any changes from my previous information. It has some slop built in, so if the numbers only change 1 or 2 it does not trigger any changes in my program…
When changing any of the assembly language, you need to understand that it is timing sensitive. That is the code calculates how long each pulse in as I keep track of exactly how many clock cycles happened. That is why in the comments of most of the instructions is a number. This is the number of clock cycles for the instruction. Some of these numbers have other characters like *@… around them to help me keep track of how these numbers are used. Some are fixed overhead, others happen in a loop, so need to add them each time this loop cycles. At one point I was changing the code again to work off of one of the timers, so I could simply grab the values and not work at keeping track of all of the instructions. Also note, the code is arranged in sometimes not obvious ways to take advantage of how pulses work. For example the calculating the address of where to store the pulse width is done long before I actually store the value there. Why? This is because once the pulse goes high I know that I have between 500-2500ms before it should go low. But once it goes low, the next one to go high could be very quick. So why not take advantage of the time when the pulse just starts to do all of our overhead work…
I hope this helps
Kurt
… holy crap… I vastly under estimated this subject, with most programming languages i can pick it up pretty quick as to get a rough idea about what its doing and all but … you 1 up’ed me on that post…
so… Basicly here is what i really want to accomplish, simply pasting in this code in the code above I put a link to on pastebin and see if this helps speed up the program execution… which obviously it does from the way you have described it how it reads all pulses in 1 go, but I still do not know if the rc code that I’m using is getting pegged at 100% cpu usage and am actually seeing slowdown issues because of it… if Im right 7 pulsin reads in a row = 140ms and if this is happening more then a couple times a second with the addition of the cpu getting clobberd with commands possibly is a speed issue which this assembly code would help a lot!
the ps2 code runs very smooth although its not having to deal with pulsin issues either… ok so…
what I’d like to do is replace the pulsin reads with the assembly code, and store them into a variable "RCInput(0)-RCInput(6) so I was not sure where your program actually stored it into an array persay? but I got where it stored it into a variable unless I missed something…
It looks like you have posted the info for me on how to change the variable in assembly and how to read it out of assembly into basic… so that’s good
and either use the front or back set of input pins…
too be honest I don’t think I’ll actually be able to understand much of it! pieces here and there…
what exactly do I need to paste into my program for it to be executed, I see that your program above had extra stuff with it, and I know your assembly program can only use either 2 configurations of pin setups front 7 or back 7…
I’m starting to grasp the basic code quite a bit and having lots of success with adding my own ideas to the phoenix, having some more head room for other stuff will be cool with the assembly bit added…
thanks for the really complicated reply! I’ll have some stuff to study up on…
–Aaron