As I say often, I’m not much of a programmer, so this might be a dumb question:
Are you basically mixing languages by writing assembly code with basic code? or is it basic code acting as assembly code?
Hi Mike,
Yes I am mixing languages here, which is one reason I like working on the Atom Pros. Here is a thread about some of it: lynxmotion.net/viewtopic.php?f=4&t=3347
So for example in some of the code that I have for the XBEE on the phoenix I wanted to pass a pointer to a string to an output function based off of some index number. I wish I had pointer arrays, which I will work on next, but instead I simply walk through the strings until I get to the right one. Could easily do that in basic, but sometimes it is just fun to do it in assembly language…
[code] GaitType = iNumButton-1
Sound P9,[50\4000]
GOSUB GaitSelect
; For the heck do in assembly!
pT = @_GATENAMES ; Point to the first of the paint names
mov.l @PT:16, er0 ; pointer to our strings
mov.b @GAITTYPE, r1l ; r1l has the gait type
beq _CI_GS_ENDLOOP:8 ; passed zero in so done
_CI_GS_LOOP:
mov.b @er0+, r2l ; get the count of bytes in this string and increment to next spot
extu.w r2
extu.l er2 ; convert to 32 bits
add.l er2, er0 ; and increment to the next string
dec.b r1l ; decrement our count
bne _CI_GS_LOOP:8 ; done
_CI_GS_ENDLOOP:
mov.l er0, @PT ; save away our generated pointer
gosub ControlOutputString[pT]
[/code]
The code is not very exciing except that it shows you can flow from basic into assembly and back. The compiler knows when you do this and it adds in the transistion code, like saving away registers and the like. You also have the ability to setup functions that are completely ASM based and also you can define portions of the code to be completely ASM, which is nice if you wish to use things like macros.
The basic code is compiled into a set of tokens, which is downloaded to the processor, these tokens are processed by an interpreter, which I am guessing is also downloaded each time as well. That is why with the IDE you can also write your programs completely in ASM or in C and have the entire chip to work with (minus the boot loader).
Kurt
Another quick update, I soldered up the extra line to the sparfun XBEE holder. Make sure it is to the one that is marked: RTS on the backside and then changed my code to use P7 and it all appears to work. Here again shows the differences between the two holders.
Kurt
Hi Kurt,
Thanks for posting that info Kurt, I’m just a little confused. Did you mean CTS or RTS?
I’m in a robot-building process right now, but I’ll soon work on the software and remote part. So I would be very interested in a working Phoenix V2.0 code + DIY with XBEE version. So if you have done additional changes to the code that you recently posted I would be interested. 
(btw, I’m in not in a hurry though, so if you are planning to do additional changes I can gladly wait).
Thanks for sharing your work Kurt!
Hi Zenta,
RTS. If you look at the ATD6 command for the XBEE it will talk about using the RTS line. I believe the CTS line can be used for the XBEE to let you know that it’s input buffer is about to be full.
I can’t wait to see what you are building 
Any hints.
The nice thing about the boards right now is that I can always post versions and then simply post an update later. I will probably post a zip file in the next couple of days when I get everything to a consistent state. That is I want my brat and hex both to work at the same time.
But yesterday I started a slight detour. That is I started writing a VB application to emulate the DIY XBEE remote
It is not very pretty and the communications still needs some work so that one side or the other does not drop the conversation, but I have been able to click on the “0” key and have it wake up, have done some movements and when I press for example the A key, the Hex sends back a message saying that it is walking which now I simply add to a list box instead of overwriting like the LCD does…
Next up is to improve this and cleanup the code some and re port back over to my Brat. I may also order a couple more XBEE and put one on Rover… And then be able to control all of them from the same remote or the PC. Also may play with maybe being able to send SSC-32 sequences over to the HEX using the XBEE. Not sure yet how, may add to my VB some way of reading in your data and/or maybe hacking on your Excel macros. I just think it would be fun to have the hex there and simply press a button on the PC to send the updated sequence(s) and then press another to test, without ever having to change wires or programs. But this may be a pipe dream.
Kurt
I have seen it! It looks awesome of course! The nicest 24 servo hexapod I’ve ever seen. I am not saying anything more… Don’t even try to bribe me with your picture of money changing hands Mike…
Actually, its 26 servos… Didn’t you notice the two micro’s
[size=150]Im sorry… I didn’t hear you Jim. You were saying?[/size]
http://www.bingo-dabbers.co.uk/blog/wp-content/uploads/2009/07/robber.jpg
Um, Ahhhh! 
I didn’t want to release too many secrets. lol 8)
I thought I would do a quick check point of code, will probably update in a couple of days maybe a week as Thanksgiving is coming.
This zip file contains the current source for the DIY remote XBEE version, plus partially converted version for the Phoenix(CHR-3), Brat, and Rover with Arm. Note: I have not tested any of the ARM stuff yet as I was actually testing on Tritrack. I still need to flush out these versions and I need to do lots more testing. This zip file also includes a simple VB application that can also talk to robots through the XBEES (So I am currently using 6 xbees (PC, Remote, Test bed, Hex, Brat, rover).
Note: the 3 robots are all contained in the same directory and have different project files for each one. This allows me to use the
same implementations of Timers, Timer supported Serin and Serout and XBEE functions on all of the robots. Some things I am thinking of changing soon include: Move all of the XBEES to a standard baud rate. Currently using 62500 as it was the fastest HSERIAL baud rate I could use below 115200 which is the fastest the XBEEs can be set to. But this is not a standard baud rate for the XBEE or PC (more in readme in zip). So I am thinking of reverting to 38400 which is supported by everyone.
I am using serin with flow control to talk to the xbees, but when flow control goes high at the end of the serin, xbee still sends maybe 2 chars which are lost. So I wrote my own to handle this. I think it works well, but maybe I should revert to serin and try to hack by sending extra bytes to be lost…
My VB app has a test SSC-32 function that on a test program I can have the PC talk to the SSC-32 through the BAP. On the test program it worked well enough to handle VER command and lynxtem retrieved the version and was able to send ALL=1500. So I will maybe integrate it into my support functions to see how hard it would be to click on connect SSC and then maybe exit my program, and see how well seq or PEP can talk to it. If PEP works, could add to underlying excel VB… But that is sort-of a side project.
Bug agin this is only a check point of the code!!! - A slightly updated version uploaded Friday.
Warning: before building/using… talk to me!!! This is really still needing some work!
Hi Kurt,
As you know I’ve decided to add the XBEE’s to the DIY too. First I want to add the four cmd switches. Since I’m not 100% sure how you’ve wired the new buttons I would like you to take a look at my little schematic here (quick and dirty hand written ). Does the schematics look correct?
Yep it looks like you are using thse more modern tools (like graph paper).
I think that looks correct!
Kurt
Ok, thanks Kurt, thats good to hear I’m on the right track.
Oh yes, I’m a bit “low tech” when it comes to drawings. Fast and easy…
Yep, I think you are on the right track. But I may be needing some work to make it work reliably on all three robots.
As I have said in some PMs is that currently I am rolling my own serial input/output functions that appear to work OK at 57600 and even run the SSC-32 at 115200 as long as HSERVO or other interrupts are not enabled. So it is working well on my Hex. But on my Rover I am having my messages corrupted by the HSERVO interrupt processing. It does not corrupt as much as the standard bitbang functions, but bad enough. I can probably find work arounds, but I wonder if it still may be easier and cleaner to use the hardware serial support. This would introduce a couple of issues like:
The Hserial can not generate 57600 (covered in a couple other posts). But could go down to 38400 which is standard baud rate and HSERIAL can do it.
Hserial with its interrupt processing also corrupts other bitbang functions. Couple of things here. Can probably ignore in some cases like for example the DIY remote control, that does not need other bit bang functions. So in theory could use without flow control pin. Note previous version was like this.
Could add flow control pin and still use the standard HSERIAL functions. That is we can manuall set the flow control pin low to say it is ok to input now and a little before we need to do some bit bang funcions, we can raise the signal back high. we could still use the standard functions for this. We could also possibly verify that no pending IOs are happening to make sure that our other output is not corrupted.
Or could roll my own HSERIAL functions that are not intterupt based. Once everything is initialized you simply wait for the flag that says a buffer is empty and you put the next byte into it. Likewise for reading, you wait until it says you have a byte available, you stuff it away and wait for the next characters. They are both double buffered so you have a little time before you lose something. Might play with this… Done it before on AVR…
I don’t know if any of this makes any sense? The image below shows a corrupted packet.
The packet is supposed to be 80, 3f, 3f, 0 but the during the second 3f the one transistion was delayed as you can see by one of the .s which is where the logic analyzer thinks the sample places are. Each bit is about 17us in length the 6 1s in the valid 3f took (.10225ms) which comes out right, but the corrupted one, took .1145ms (so the transistion was delayed by 12us). I am sure that makes it a lot clearer 
Kurt
Well, it seems like it make sense, I’m just not sure if I’ve the necessary sense to make it sense though…
I’m just hoping I’ll get it all to work.
It seems like you have used all the available ports on the BB2 now? I have been thinking of adding an extra potmeter, maybe disconnecting the speaker would free up one port. Do we really need the speaker? We have the display on the DIY (for information) and there is already one speaker on each robot too. Just a thought…
I’m also trying to make a dual setup with both the XBEE and the DM8 onboard. And add an powerinput connector so that its possible to use the DIY transimitter while charging the battery.
Hi Zenta,
we have a couple of options here. There is a version of the transmitter program in the zip file up there that is slightly older, that uses HSERIAL instead of my Serial input/output functions with flow control. I believe it was working fine and it does not need the extra pin, which leaves you one free.
One reason I was switching all of them to my own serial input/output functions is that the fastest “Standard” baud rate that HSERIAL can do is 38400 and I was trying to get the xbees up to either 115200 or 57600 which are standard serial baud rates for the XBEES and PCs. We can however run it with HSERIAL at 62500. Before I was trying to run them all at the same baud rate as I read this was necessary on the web (For example there is a tutorial up on Trossen). However today I tried running an XBee on my PC at 38400 and had it talk to my Hex robot at 57600 and it worked. So that implies that we could for example run the Transmitter at 62500 with HSERIAL as there are no other serials to screw up 
. Then the Hex can run with baud rate of 57600 with Flow control.
I was in the process of writing my own version of HSERIAL that does not do interrupts (Written not run yet). But I am thinking of first trying out using HSERIAL on the Rover again and seeing if the interrupts cause any problems (as we already have hservo interrupts). If so I may add some quick and dirty optional flow control that we can simply say I don’t want to process any inputs right now… This was my middle option. It is not as eloquent as the full blow assembly language version, but then again others may understand it
Kurt
Hi Kurt,
I believe you are thinking of the RTS line on the XBEE that would free up one port on the BB2?
To be honest I don’t have any strong opinion of what way to go. I just want to get rid of the slow RC pwm reading
So you are saying that using the HSERIAL version on the Phoenix V2.0 code didn’t mess up anything, and worked perfect? One thing I’ve been thinking would be great are if I could use the DIY with XBEE together with the ArbotiX board one time too. Using 38400 would be a safe way to go then? But at this moment I’m only working with the BB2’s, so that open the non standard option (62500)?
I’m in the process of mounting the 4 extra switches (they are mounted actually) and some other stuff. When I come to the software part I’ll let you know.
I am saying the hserial version phoenix was causing some of the jitters I was seeing where the serout to the SSC-32 was being corrupted at times. So I went to the the non-hserial version. But the HSERIAL version was fine in the DIY remote, but HSERVO was corrupting the non-hserial stuff on the rover, so I am now hacking up an hserial version for this one…
So yes the HSERIAL version can free up a line to the BB2 for the remote. The way I am updating the code I may make the HSERIAL have an optional RTS line so I can then try it again in phoenix. IE when I am about to output all of the stuff to the SSC-32, you lower the RTS line wait a little bit to make sure it has time to process up to two more characters coming in and then you output the commands to the SSC-32 and then you raise RTS again to allow new stuff to come in. This would be #ifdefed in the code so if an RTS line is defined it will work if not then that part of the code won’t be there.
Right now trying to clean up a lot of my helper functions to centralize a lot of the serout/serins such that the #ifdefs are not everywhere…
Yep I liked the idea that the processor is not all hung up waiting for the PWMS so you have time to do other things!.
The ArbotiX board looks interesting, but yesterday I ordered an AxonII (societyofrobots.com/axon2/) to try out. I thought it would be fun to have a “C” version of the phoenix code running on this and then maybe for the fun of it port the C back over to the BAP and see what the differences are. I think the BAP may be much faster especially with the math, but having all of those serial ports and timers and the like will be nice. Would also be nice to then try it out on the ARC32 board
Too many options , but a long winter 
…
Ok, I believe I got it now. Thanks Kurt!
So if I got this right: Use the HSERIAL version on the DIY (no need for RTS) and run the “non-serial” version on the Phoenix code? BTW, I do like that you are using project instead of single .bas files I find it easier to get an overview of the code.
The AxonII do look interesting too. But I found the ArbotiX very convenient since I already have a bioloid comp kit thats just collecting dust.
I do find the long winter very robot friendly though