Hi Guys,
As promised the Alfa Release of Phoenix code V2.1.
Current status of this release:
I placed the alfa version in this hidden development section so you can have a preview.
Please feel free to place any comments in the original topic.
Thanks!
Xan
PhoenixCode.rar (17.1 KB)
Thanks Xan,
I will give it a shot and have some fun!
Kurt
Hi All!
I thought I would do as Xan asked and do the conversion from TimerW to TimerA/B. Also I uncommented the enable/disable interrupts, which on my T-Hex helped!
But: I did a little more messing around, that I am not sure if you will like or not like… As they say it is easier to ask for forgiveness than permission. That is I moved all of the SSC-32 (Servo Driver, GP Player ) and Timer code to another file. Why? It would be real nice to have a common code base also with Arc32 version that does not use the SSC-32. I have versions of the Arc32 (previous code base), where the Servo Driver works, plus I have my roll your own GP player that works… May need/want a couple of other call outs for other functionality (Does sequence X exist, init…), but should be self contained. Why Timer code? Because the new HSERVO2 code has it’s own built-in timer. Would be nice to use it and not need an additional timer.
Thoughts?
Part of this is a question for Jim, that is in the near future do you expect to start packaging up versions of the Hex robots with Arc32s?
If you don’t like the idea, that is fine, I can easily make the timer changes in the other code base as well…
Edit: I added a second driver file here with the starts of Arc32 version. I think most if not all of the code is in here now, but have not tested it yet…
Kurt
Phoenix21k.zip (22.2 KB)
Great work Xan!
Looking forward to try it out.
Kurt, will the DIY/XBee control file work on this without any modifications?
Not sure yet, will try it soon. First I will try the PS2 on Arc32 version of phoenix. Then I will work on making new version of XBee code. Hopefully very little will need to change. In my version that I posted there I have a time conversion function as to abstract away the time conversion constant(s), which may impact the code.
Also Zenta, could you send me your version of the GP sequence feedback code, would be fun to play with.
Kurt
Hi Kurt,
I did not had the time (yet!) to compare the two versions to see what you’ve changed. But your suggestion about splitting the driver and timer subs into a different file it totally fine by me. Certainly if this makes the code more flexible.
I’ll get back on this once I’ve compared the files.
Thanks for your input!
Xan
Zenta,
I had to change ALL files for this update. The Control and Config files are both changed but the changes are small and easy to make. I made a list of changes on the top of each of the files.
Kurt has to answer the XBEE question since I don’t have it.
Please feel free to test out the alpha version. 8)
Xan
I do not have any immediate plans to offer a hex with the ARC-32. My agreement with Basic Micro was for them to make the tutorials for our bots and their electronics, so we could sell them as combo kits. They took a stab at it, but what they submitted was unusable, and I don’t know that we will be able to create them either. Soon we will have propeller and arduino boards as well. These will certainly draw more people to our products and the forum. How we will integrate them into our kits is still an unanswered question…
Thanks Zenta, Your video showing this looks great!
Xan, what do you think of integrating some of this into this release. I could take a stab at it with my current test version, probably both PS2 and XBee and if you like it you could incorporate into the main official version.
I have not tried moving the XBee over yet. Still playing with PS2 and ARC32 stuff. Arc32 stuff I think is mostly working. Issue with GP player with one sequence having data problems, may be caused as my Phoenix has a prerelease Arc32 board in it. I should maybe break down the phoenix and replace it with a production board. I did put some recovery code in so it does not hang now. But I have run into an issue with the PS2 on the Arc32, that at times it falls out of Analog mode. My Arc32 version detected this and reran the init code. You will run into this if you run a sequence and during that time you do not do any PS2 input and something times out. I updated my copy of the code to detect this and recover. It currently looks like:
In control Input I added the code to read in the current mode and if it is not the padmode call back to the init… But Not all of the init…
[code]ControlInput:
low PS2SEL
shiftout PS2CMD,PS2CLK,LSBPRE,$1\8]
shiftin PS2DAT,PS2CLK,LSBPOST,[DS2Mode\8]
high PS2SEL
pause 1
if(DS2Mode <> PadMode)then
gosub RetryPs2TestInit ; use secondary name so does not depend on if XBee is also defined…
endif
low PS2SEL
shiftout PS2CMD,PS2CLK,FASTLSBPRE,$1\8,$42\8]
shiftin PS2DAT,PS2CLK,FASTLSBPOST,[DualShock(0)\8, DualShock(1)\8, DualShock(2)\8, DualShock(3)\8, |
DualShock(4)\8, DualShock(5)\8, DualShock(6)\8]
high PS2SEL
pause 10 [/code]
In the init function I have:
[code]InitController:
#if PS2DAT = 0
PUCR5.bit0 = 1 ; Note these pull-ups may not be sufficient for all PS2 remotes.
#endif
#if PS2DAT = 16
PUCR1.bit1 = 0x1 ; 16 is on H8 P11 which has a pull-up
#endif
high PS2CLK
LastButton(0) = 255
LastButton(1) = 255
BodyYOffset = 0
BodyYShift = 0
RetryPs2TestInit:
…[/code]
That is I don’t reset the other variables… You can obviously disregard the other IO pin init code… I have uploaded a zip file that has a project that allows me to test multiple projects. It has multiple config files with ifdefs, it has a config_config file that allows me to choose which one. I will add an XBEE control file here as well and maybe an RC and maybe a modified RC (one IO line), that I can change a setting and try. Obviously this is not the way we would distribute it, but it does make it easy for me to try different things out…
Update: With ARC32 version I run into issue that at startup the robot servos would all jump… I figured it out that The function GOSUB CommitServoDriver was being called even when the robot was not active. It was in this function that I am calling HSERVO. I moved the call inside the IFDEF for HEXON and the Arc32 is happier. The zip file was updated with this change.
Phoenix21k.zip (24.4 KB)
Hi Guys,
As I mentioned yesterday, after seeing your (Zenta’s) variable speed general purpose sequences in action, I personally think it would be great to include in 2.1. Xan as I mentioned, I am willing to do the work and let you clean it up and bless it or if you prefer to do it yourself, that is great!
If I do it, I am thinking about completely reworking how some of the GP stuff is done. In particular, I wish to get rid of the callback code. Instead I wish to have convert the GP code from the current stuff that you call and it does not return until sequence is done, to instead have one or more state variables, and we call it multiple times. When we return from the call, if the sequence is still active we jump back up to the start of the main code loop which calls off to ControlInput. We can then put all of the Feedback code into the appropriate Control Input functions and also grab the new inputs from the user and if appropriate change how the current sequence is running. This will have a couple of side effects, which includes reducing some of the duplicated code and probably also take care of the PS2 on Arc32 issue I mentioned last night…
Thoughts?
Kurt
Hi Kurt,
I’m not sure I totally get all the changes you want to make but please feel free to add the GP player as described.
I think I’ve got some robotic time this evening and I want to focus on adding the extra DOF and the BodyRotation with variable Center of Rotation.
We can merge both version when done.
Thanks for helping!
Xan
Hi Xan,
I see that you have already done the first part of the changes I suggested. That is it does not hang out in the GP Player anymore, but has a few different states and does the jump back up to main. (Need to change my Arc32 version to do the same. Then I just need to integrate some of Zentas stuff in 
Plus Convert the XBee driver to the new code.
Kurt
Hi Kurt,
At this right moment I’m looking at your version you posted last. I think it is a good idea to have all SSC related stuff in a separate file called “driver”. This means communication from and to the SSC. (Servo drivers, GP player stuff). I’m still a bit in doubt if we need to make a separate file for the timer functions or leave it in the driver file.
I do want to get rid of all #ifdef’s but that should be ok since we can simply add the SSC/BAP or ARC driver file to the project to swap timers and SSC drivers.
I remove the #ifdef’s where I think they can be removed. I would like you to double check my changes since you’ve got a bot with an ARC onboard. Hope to post this in a few hours.
Edit: I saw you moved the commitServos sub. You should return it since the FreeServos function isn’t working without it. I wanted to be one call for all updates but I need the extra 600ms pause when powering down. That’s why it’s double called.
Thanks, Xan
Thanks Xan, Yep I did move the call, as it was causing start up problems for Arc32 version. So if you need it there I need to put a hack in to Arc32 version to not do HSERVO moves in this case.
Yes we could still have timer stuff in main code base, but Arc32 does not need it as HSERVO2 has timer functions built into it. Just finished converting the Arc32 GP player to use the states, now to work on XBee stuff and Zentas feedback…
Kurt
Forgot to mention. I could get rid of the multiple configuration stuff by having separate projects for each configuration, which I will do in the end. I just find that the multiple projects makes the IDE confused when several files are used by multiple projects. It does not know at times to save my changes when I do builds or the like.
Kurt
Hi Kurt,
Here is the package containing the phoenix code with separate SSC driver file.
I have removed the #ifdef’s. Changing from SSC/BAP to ARC can be done by loading the correct driver file in the project. I hope you are ok with this since all the #ifdef’s make the code so hard to read.
I like what you did with the reinitialize of the PS2 remote so that’s in there.
Please let me know what you think.
Xan
p.s. XBEE and ARC files are not in there since you have the correct versions.
Edit: This is the current list with updates in Alpha 2
PhoenixCode_Alpha2.rar (18.1 KB)
LOL, looks like we are really working at the same time here 
Last update for this evening. Got the shifting Center Point of Rotation in there:
On the PS2 remote, when in rotation mode (L2) you can shift the center to the Head and tail by holding down R1 or R2.
Xan
PhoenixCode_Alpha3.rar (18.2 KB)
Hi Xan, Grabbed the update and am splitting my projects into 4 projects:
T-HEX - PS2
T-HEX - DIY XBEE
Phoenix - Arc32 - PS2
Phoenix - Arc32 - DIY XBee
Hi Xan I know that you don’t like #ifdef type things. But for example PS2. On Arc32 you will not likely use pins 12-15 for PS2. I use P40-P43 as it has Pull-up resistors. Could put #ifdef for ARC32, but less obtrusive, maybe allow the user to define the pins in config file and then have main code:
#ifndef PS2DAT
PS2DAT con P12
PS2…
What do you think?
Also noted with your current code, you removed all Arc32/Bap40 support to use with SSC-32. That is TimerA is only supported on Bap28 (H8/3694). TimerB is the equivalent for Arc32 and Bap40 (H8/3687). So your project will not build for those platforms…
Kurt
