Thanks for the feedback! Some of the points are new to me so you need to fill me in a little bit. I would be happy to discuss them with you.
1) Earlier I converted my code from TImerW to TimerA... Probably not that important, but I was able to reduce the number of interrupts per second. But I had to add a multiplier and divisor to to convert the clock ticks to milliseconds.
Does the rather slower TimerA has an high enough resolution to sync both BAP and SSC? I think it is a good thing to reduce the amount of interrupts. Can you provide me an adjusted version of the alpha release with this new timer?
1a) I have had a few occasions when a leg would act funny or jerk a little randomly, and found that if the timer interrupt happened while doing serouts to the SSC it could corrupt the output, especially at faster baud rates. So my versions have a set of disable/enable Timer interrupts that bracket the serouts to SSC. (I set which interrupt I am using as a constant as it changes for Bap28 versus Bap40/Arc32). With Timer A you only have about 7 or 8 interrupts per second, so won't lose interrupt during the serout code.
I've seen the enables/disables but I wan't really sure what they where doing there. So I commented them out. I will uncomment them.
1b) Some input controllers like XBEE may use interrupts (directly or indirectly through hardware serial port). So I also added call outs to the Control code that said, disable your interrupts now/ It is OK for you to Enable them again.
Isn't it a better solution to disable/enable ALL interrupts when going in to critical sections like updating the SSC? This way we don't need to add code in the "core" file which is only used when the bot is controlled by XBEE.
On some robots, that I use the pS2, I also have an XBEE on P14-P15 so I need to move the PS2 to another set of pins. At least half the time on Bap28 and Lynxmotion PS2 remotes the internal pull-up resistor on the Basic Atom Pro is sufficient for the Dat line. This works for P0 and P16, which on the Bot Board 2 is the only reasonable locations to start a group of 4 pins... (P4 does not work as P6 and P7 have lower voltage and did not work. P8 does not work as P9 is used by the speaker... But if needed could probably use the pull-up on that pin as well...
So in my PS2 code I start the InitController like:
;[InitController] Initialize the PS2 controller
#if PS2DAT = 0
PUCR5.bit0 = 1 ; Note these pull-ups may not be sufficient for all PS2 remotes.
#if PS2DAT = 16
PUCR1.bit1 = 0x1 ; 16 is on H8 P11 which has a pull-up
I think you're a one of a kind guy, having 2 remotes on one bot!
No serious. Most of the time I use my DIY remote while programming / testing. Once the software is ready I simply swap receivers and try the PS2 remote. This should be good for debugging / testing but I doubt this has any value for most of the users. But please, let me know if I'm on the wrong track here
Added Maybe? Recent Zentas (with a little help) enhancements to running GP Player. Again XBee code needs to disable interrupts during the issuing of commands and query back from the SSC-32. (Also needed a slight pause). But in addition to this there were call backs added to this code to the controller code such that the it could give additional feedback to the user. Also it allowed the controller to update the running of the sequence.
Along this same line, my versions have some places where the main code may tell the control code about some events, which allows the code to inform the user or the like. My additions may not have been generic enough in that it said XBee Play a sound... But this could be updated to be something like: ControlEventCallBack[EVENT]: Where we could define a set of events like (low power shut down ...)
Isn't it possible to have the feedback from the bot to the remote defined in the XBEE file? The idea sounds very interesting. Having a predefined set of events that can be used to transfer information from one part of the code to the other. I'm totally in to this but I think it's a good idea to split this idea into a new topic and work this further out. In the mean while we should get our TA base version (v2.1) ready. I think the event stuff should be added later on since we still need to test the idea...
Thanks for the input and let me know what you think!