WARNING: The hserial system has changed with the latest release of studio 2.0.0.0, here is a link to the release notes. Nathan updated the notes last night: forums.basicmicro.net/news-f481/ … t9437.html
With these changes none of the current XBEE projects will build. I did a quick update to the code and did a quick run test both on the Arc32 version of the phoenix as well as the BAP28 version (chr-3). I also verified that the transmitter would compile, but I did not test it…
Kurt
Warning: Check to see what debug levels that are set in each file. If in the phoenix code I have some debug options turned on the inputs will be limited (as to make it easier to trace what is happening and to make this work the same in my C code…) Also verify which input options are enabled. For Arc32 make sure the RC input mode is disabled. DIY XBEE - Packet mode.zip (273 KB)
Kurt,
When compling the DIY Transmitter with the DEBUG on i get C:\Program Files\BasicMicro\Basic Micro Studio\bin\ld.exe : region text is full (d:\diy xbee - packet mode_sep_22_10\xbee projects\diy transmitter.bin section .text) error. I made sure it was the only one selected. compiles fine if i select any of the others.
As when CURRENT DL: is selected it displays the same as the CRRENT MY: Switched out xbee’s and the DIY(only) see’s that module as MY 00
I restored all my modules back to defaults and upgraded them to 10E8
I’m still having issues I’m taking it all apart and checking all my connections. I tested my XBEE’s and can communicate with them wirelessly using my ARC32. I’ll give all a try again
Actually in this case I was thinking of doing it on the robot side. With the Arc32 you should have lots of space. That way we can see if it is receiving anything and talking properly to it’s processor. If it looks like it is returning proper information for My/SN… than maybe try the VB application and see if it can talk to the robot. This way we can start to localize down which side is not working for you. I am pretty sure your transmitter is talking fine with it’s xbee as you were able to do the query to see what other xbees that are out there.
Hi did you hit the ENTER key on your keyboard after typing in T7? Normally the command will echo something back. For example on my machine (Not sure if C or basic on my phoenix right now…
[code]Phoenix-Arc32 keyboard monitor
D ]] - Dump EEPROM memory
O - Enter Servo Offset mode
S - Download sequence(s) - VB call only
T ] - Set or show debug Trace level
V - View Sequence
: t7
Current Debug Level: 7(7)
[/code]
Also did you have a chance to add in the debug code I mentioned above to see if your robot is talking properly to it’s XBEE?
That was adding something like:
#ifdef DEBUG_XBEE
gosub APISetXBeeHexVal"D","L", wNewDL]
hserout "MY: ", hex wNewDL]
gosub APISetXBeeHexVal"D","L", wNewDL]
gosub APIGetXBeeStringVal"N","I", @_bNI, 20], _cbRead ;
gosub APIGetXBeeHexVal"S","L",0x0], _lSNL ; get the serial low, don't enter or leave
gosub APIGetXBeeHexVal"S","H",0x2], _lSNH ; get the serial high,
hserout "DL: ", hex wNewDL, "X._NI: ", hex _lSNH, " ", hex _lSNL, "(", str _bNI\21\13,")", dec _cbRead, 13]
#endif
As I mentioned I would add something like this to the end of the InitXbee function in (phoenix_control_diy-xbee.bas). Some of the variables may not be defined there. You could probably start off by just doing the My and DL and see if that looks correct.
I did press enter after the T7 and no respone. I added #ifdef DEBUG_XBEE
gosub APISetXBeeHexVal"D","L", wNewDL]
hserout "MY: ", hex wNewDL]
#endif to the end of the InitXbee function in (phoenix_control_diy-xbee.bas). no response
I tried it at “Enter: Init Controller” and it displayed “MY: 0”
I would like to step back a second and understand where you are so I can better help.
Which version of the Basic Miccro Studio IDE are you using?
Make sure in the config file that USEXBEE con 1 is set. You may want to make the USEPS2 to be commented out. Also make sure the USERC if defined is commented out.
In the …-xbee.bas the debug statements are defined: I have
;[DEBUG]
DEBUG_XBEE con 1
DEBUG_VERBOSE con 1
DEBUG_ENTERLEAVE con 1
Ok you say if you put the hserout at the end of the function (before the return), you are not seeing anything, but if you put it at the start you are. This could be a sign that the program is crashing or hanging, which would also explain why the debug terminal did not show anything… In cases like this, I would do the following:
Go to the main file (phoenix_v21.bas) in the init code, like right after it set Eyes = 0
and add:
wDebugLevel = 0xffff
That should default to all debug messages being output…
I would then go into the init xbee function, and add some more debug hserouts to see where it may or may not get to. Like put one inside the start of the code that conditionally compiles with the RTS line to make sure that code is not included.
Hi Kurt,
Im using Basic Micro tudio 2.0.0.0
After following all your instructions, the speaker stopped chimming, the terminal displayed so much data i wasn’t able to read it.
and the XBEE modules really started to blink.I back tracked and commented out all the debug stuff. Now all seems to be working.
once i select the arc32 board the XBEE’s start to blink real fast. selecting “0” the speaker chimes and the servo’s move.
I checked the Phoenix-Arc32 keyboard monitor on the terminal and selecting T7 returns “Current Debug Level: 7(7)”
;--------------------------------------------------------------------
;USEPS2 con 1 ; Do we use the PS2?
USEXBEE con 1 ; and/or do we use XBEE?
;USERC con 1 ; and/or do we use RC
;--------------------------------------------------------------------
Once I commented out USEPS2 the speaker started working as you mentioned. After commenting out USERC the othe things
i tryed seemed to work.
Could this be due to i dont have a PS2 or RC module installed?
Now to enjoy a cold grog
Thank you for your patience
My guess is the RC stuff was getting in the way. Actually the code was not completed or tested yet The PS2 stuff may get in the way of some stuff, but for the most part it will simply just try to toggle a few IO ports and see it is not getting anything returning. The code was properly set up such that if it is not making contact with PS2 to keep trying the XBEE.
Warning: If you downloaded the recent package you should verify what input methods are enabled and also check to see what debug options that are set. For example in the Bap28 phoenix code the file up there probably had some debug either pin or body calcs enabled in the main source file. This very much limited the valid inputs as to make it easier to verify things on multiple platforms. But it very much restricted usage, like rotation while in walking mode did not work… To fix simply comment out the debug config statements at the start of the file. Those like:
;DEBUG_MAIN con 1
;DEBUG_ROT con 1
;DEBUG_PINCALCS con 1
'DEBUG_BODYCALCS con 1
'DEBUG_GAITS con 1
In the Arc32 version make sure that the RC input mode is not enabled and only enable the PS2 and/or XBEE. The code can handle both, but if you only have one only enable one… This is in the CFG file. Mine currently looks like:
;--------------------------------------------------------------------
USEPS2 con 1 ; Do we use the PS2?
USEXBEE con 1 ; and/or do we use XBEE?
;USERC con 1 ; and/or do we use RC
Soon I will test the RC.
My guess is that you have no sound being generated at init time and the IO pin for the speaker is left as input and floating which may be the issue… Try adding something like the low cSound in the init section of the main source file. I put mine right after the part where it inits the LED values…:
;Turning off all the leds
LedA = 0
LedB = 0
LedC = 0
Eyes = 0
low cSound ; make sure our sound pin is initialized as an output so we won't get buzzing...
Kurt
Just to make sure, the speaker - has the radio shack part number 273-092 on the back of it. You have a red wire which you plugged into the signal for IO pin 19 (inner row of pins) and the black pin is connected to ground (outer most row of pins). I did this today to a second Arc32 that I use for testing and I am getting the appropriate sounds… If everything else is working you can always remove, this is just for making it easy to know something is happening…
Well I went through the process of the servo offsets(O), got done with that, and I had already hooked up a speaker as well as the ps/2 controller, unfortunately the ps/2 controller stopped responding just before I went to use it(red light on the ps/2 controller started flashing), and just the green light on the ps/2 module is on solid). So I unhooked the ps/2 setup and just applied power to the ps/2 module and all I get is a solid green light, no flashing red light at all now. Any ideas??
Hi Phil,
Not sure on the speaker, maybe try changing to another IO pin. Just need to move plus change the define in the CFG file. Note: make sure to move to IO pin that has an actual backing pin as marked as Standard IO capable marked in the spec. IE pins 8-15 will not work nor 24-27
Hi Charley,
Nope, sounds to me like the PS2 may have gone south. I had one do that recently as well, mine was different, I could never get the two to sync, even if I only applied power. I ordered a replacement which I received last week and it is working again. The only thing I would make sure of is to make sure where you plug into is +5v and not one of the VS terminals. I have found that they don’t work on higher voltages. Side note, recently I was reading that some controllers will not work at +5v either. That the actual PS2 game console runs at something like 3.4V. There is more information up on the Curious Inventor: store.curiousinventor.com/guides/PS2
I’m taking it all apart and checking all my connections. I tested my XBEE’s and can communicate with them wirelessly using my ARC32. I’ll give all a try again
This has been a very good learning experience for me