I think Jim was simply saying (without putting words in his mouth) that he would love to see the TA at least limping along. It would be great if it was enabled for as many people out there as possible and if you have to sacrifice other functionality to do so, that would be fine… But that is my reading of what he said.
Xan, your suggestion of simply swapping in the Arc32 in with the SSC-32 to continue work, is what I thought yesterday as well, which is why I built that version of the SSC-32 that would compile on Arc32… I liked the idea as well as I mentioned before it is easier to debug when your serial messages don’t get scrambled. But once we have it up and limping along we can look at the sizes and conditionally trim out as much as necessary (if any) to make it work on Bap28 with PS2…
As for Arduino… When I have free time after new drops of BAP code, I will integrate it into my Arduino code base and probably use my TH4-R robot to try things out there. Again assuming the code changes are done where the controller specific stuff like (stop Leg(s), Get Leg position, or Get Leg Servo Positions) are put in the appropriate area, and separate from the calculations and the like, it should be easy to migrate between the different configurations.
Ah, ok. Why aim for limping if it can parade like a ballerina? Sry, if I’m gonna put my name under it, I’m gonna do it right
Yes, I know. You mentioned it in your post. If Jim is ok with it, I’m gonna swap my board this evening and continue developing. Kåre, is it ok for you to stack an SSC on the phoenix for now?
Yes, I already placed the driver specific functions in the driver file.
Yes Kurt that is it… Everything is fine, I am just seriously bumming. We’ve just about got the A-Pod ready to go, but now it’s dead. $12,000.00 in parts and months of work and it’s just a lump of nothing with foot sensors. My decision, I’m an idiot. I’ve spent so much on getting away from BM’s stuff because they are no longer a reliable supplier. My ability to move on has not been a tremendous success so far. I guess it’s all about expectations. If we were starting out to do TA from scratch with the existing hardware I doubt very seriously the resulting code would have multiple gaits, the ability to play preset sequences, and the like. I just didn’t see this coming, as nothing in the hardware has really changed. Why didn’t we know this was a dead end a long time ago? I guess it’s because the awesome Studio IDE doesn’t have a good way to tell you how much memory is left? I appreciate you guys and your willingness to help us here. I also understand who want’s to go backwards, it IS counter productive. I still need a good affordable small controller that is not anemic when it comes to code space and speed… sigh
As I mentioned I am in agreement with the lets get it going!..
Sorry bad choice of words (limping). What I meant was that if we can get it to dance at a parade like a ballerina, but not at the same time tell jokes at the comedy club that might just be fine Now back to real world stuff. What I am trying to say is that if we can get the TA stuff working well, on a BAP28 with SSC-32, that would be great. A lot of people may want to trade off other functionality to get this. Things like:
a) PS2 only - That saves 5K over DIY XBee
b) Turn off GP player: that saves ? - This may be easy trade off on this project as I have no sequences for T-Hex anyway…
c) Maybe turn off Balance Mode (unless code needed by TA stuff…)
d) Turn off eyes
e) Turn off Translation or rotation support from PS2…
f) Turn off some gaits.
…
Again some may be very happy to just be able to make their Hex go outside and dance…
Update: See Jim has new post… Personally I think we can get this working well both ways… Need to ask more why A-Pod is dead?
This mean that I’ve to replace the ARC-32 board and then stack the ARC-32 on top of the SSC-32. The servo wires isn’t long enough for vice versa. But I could always do it for the simplicity when sharing code, but I still think the same about the ARC-32 + SSC-32 combo… .
A side-note: Jim, why does the ARC-32 cost ~100$ from Lynxmotion and ~90$ from BasicMicro?
It’s sad to hear you saying that A-Pod is dead. I hope to get time to work out a PS2 solution for you .
Assuming that we can get the math and algorithms and delays and the like to work, with any of these configurations, I will do my best to make it work well on all of the different configurations. I personally have not given up hope on the default configuration. But as I mentioned I think it is a good idea for Xan and myself to switch the T-Hex to Arc32 to make the quickest progress. Studio does tell you how much memory you are using up both data space and program space. Only in the case where you run out of space does it completely choke. Xan you can simply pick up my current SSC-32 file and merge it into your current version. Real simple, just some #ifdef code for checking BASICATOMPRO28 or not and defining the timer to be the right one for the platform and also the changes to the time conversion constants… Once you have this you can simply tell the compiler you have an Arc32 and do a compile. This will give you the program space needed, from this subtract something like: 31744 and you can see how much you are over. The calculations are not exact as the underlying BAP libraries may slightly change as well as tokens, but my current T-HEX SSC-32 PS2 on BAP28 takes: 21472 and on Arc32 takes 21502, so they are not far off.
As I mentioned, we can turn things off and have different controls…
a) PS2 uses about 5K less than DIY XBee
b) In the above numbers, I have added #ifdef around GP player support, this saves: 3100 bytes (now have 10272 free bytes)
c) Turn off single leg mode: saved 948 bytes (Now 11220)
I personally think you should not need to add the SSC-32. Yes that implies that we will have to port this quicker to get you up and running, but I think the changes can be contained. That is if we have abstracted out, how we stop the servos, get their positions and get the notifications on when the contact hits, the rest of the code should be unchanged… But that is my 2 cents.
A-Pod…
It’s mainly the documentation and the lack of a known control solution. We have a tutorial that shows you how to wire up the leg switches. But in fact it will never work on that platform. So what to do? Remove all the info. That sucks, but that appears to be the only option. I know Kåre was planning to help with the code, but I’m out of the loop and have no idea where that is at. Kåre, maybe you could incorporate the switches to stop the bot from walking down the stairs or something? But currently we have no code for A-Pod anyway. I shoulda stayed in bed this morning…
For the same reason they sell me motor controllers, then change everything and not tell me, then lower the price and not tell me, and make version 2 to eliminate version 1 and not tell me. I spent $30,000.00 on their new stuff, and he cashes the check and turns around and makes everything I bought obsolete before I can even sell it. There is -0- regard for documentation, and changers happen on the fly with no announcement. They are a supplier from hell. I had to buy $30,000.00 worth of Atoms because he was telling me he was going to run out. He’s asked me several times if I plan to continue to buy Arc-32 cause he was planning to discontinue it. Why Kåre, because they are not good at what they do. And they do not care about the end user or distributor at all.
It’ll be fine, no worries. The Arc-32 will be changed to $90.00 today. Thanks for pointing that out.
I just had a chat with Jim about the micro controller stuff. As for development I think we all agree that swapping the BAP28 for the ARC32 will be the fastest way increase memory.
I also think that having the ARC in combination with the SSC is a silly end solution. Like Kurt says it does make debugging easier since we don’t have problems with the interrupts messing up everything. Once we get TA to work we could see what we’re gonna use in the final setup. Could be one of the new boards in combination with the SSC or just the ARC.
Kåre, you’ve an ARC only setup on the phoenix now. If you want, you could jump ahead and use Kurts driver to try the ARC only solution. The other option is to extend some wires to get both boards stacked.
Any suggestions on the ARC pin mapping? Kåre you got it already connected, where do you have the sensors attached?
On what IO pins to use, it may depend. That is, if we wish to have the ability to detect when the leg hits the ground using an interrupt. That would probably imply using the WKP interrupts on the BAP type hardware. On the Arc32 these are on pins (19, 18, 17, 16, 0, 1) for WKP0-5.
It looks like the IO pins conflict a little with our previous configurations for Arc32, but I don’t think too badly. Things Like Eyes and Speaker. Note: I often plug in a cheap speaker like the ones from radioshack (radioshack.com/product/index … Id=2062406), into an IO pin on the Arc32, such that I still have some sounds… So far I have only fried one.
Where can I define the I/O for the XBEE? Both Rx and Tx need to be defined somewhere.
Also, the RTS needs a low voltage (3.3V) signal, any suggestions?
A few post back you told me that I “only” need to change the timer to get the SSC driver to work with the ARC. You also said you could upload the driver file if I would need it…
I thought it would be a good idea to dig in to the timer myself to. ASM has really really been a long time so you have to clear some thing for me
HANDLE_TIMERA_ASM
push.l er1 ; first save away ER1 as we will mess with it.
bclr #6,@IRR1:8 ; clear the cooresponding bit in the interrupt pending mask
mov.l @LTIMERCNT:16,er1 ; Add 256 to our counter
add.l #256,er1
mov.l er1, @LTIMERCNT:16
pop.l er1
rte
If I overlook the asm code it doesn’t look logic for me. So I am defiantly on the wrong path here. This is how I read it with help of the H8/3694 manual.
push.l er1
moves the register er1 upon to the stack so it can be used by calculations. Why er1? is it linked to TimerA? Can’t find it in the manual…
bclr #6,@IRR1:8
Clears interrupt bit 6 from IRR1 which is the overflow bit of TimerA
mov.l @LTIMERCNT:16,er1
The manual says that is move destination, source. So you move the value of register er1 to the variable LTimerCnt. Am I right or is it the other way around?
add.l #256,er1
Add 256 to register er1. Not sure why…
mov.l er1, @LTIMERCNT:16
moves value from the variable LTimerCnt over er1. Doesn’t seems logic for me… Still looks like it needs to be the other way around
pop.l er1
Gets the value from the register
More questions:
Why is Timer Mode Register A (TMA) set to 0? doesn’t it need to set to another mode?
I really feel like a ASM noob here. LOL This totally is something different then high lvl C# dotNET
Looks like I got some robotic time after all very late today (we finally got or little boy to sleep…).
I just had my Phoenix with ARC-32 up and running again. Had to do some testing to see what input was connected to every foot.
@Kurt, I thought I saw the file somewhere. Didn’t look al the first page though. sry, my bad.
@Kurt, if you have some spare time for this noob. Could you give me some more detailed info on the ASM part a few posts back? Would really appreciate it…
@Kåre, Thanks for the pin numbers. We’ll use those.
push.l er1 - pushes ER1 on the stack, Whey er1? Because I used it. The interrupt handler must preserve all registers it uses. Could have used er0, or er2, or… but I used er1… Good to minimize how many you have to push/pop as each push.l and pop.l takes 10 clocks if I remember correctly.
Yep for the bclr #6
mov.l @LTIMERCNT:16,er1 - Other way around. The @ also indicates indirect. So this says to move the long value from the variable lTimerCnt to the register er1. Note: ASM is case sensitive where basic is not. Basic UPCASES all variable names, which is why it is LTIMERCNT.
add.l @256, er1 - adds 256 to the register. Why because we are counting the number of timer tics and we are using timer A which is 8 bits so an overflow is 256… When we build the tick count we add in the number of tics from the hardware register to get the actual count. Alternatively could have kept just an overflow count and then shifted it down 8 bits when we used it…
Setting TMA=0 as this gives a timer resolution of clock/8192, which is as slow as I could get… So we only get a timer overflow every: 8192*256 clocks: 2,097,152 So we get 16,000000/2,097,152 or about 7.63 times per second… The conversion factors I defined convert the actual counter into MS.
Kurt
P.S. - Yep Asm is a bit different than C# (one of these days may have to learn this - but may be hard to teach an old dog a new trick ). I have been doing C/C++ forever, Also have programmed in or debugged using many different processors with many different assembles… I like the H8 as it has 32 bit registers and instructions are pretty easy to learn and use…
Thanks for the good explanation. Swapping the source and destination of the mov command makes much more sense. The manual got me in the wrong direction. Here is a copy of what it says (pag. 22)
Symbol Description
Rd General register (destination)
Rs General register (source)*
MOV B/W/L (EAs) → Rd, Rs → (EAd)
Moves data between two general registers or between a general register
and memory, or moves immediate data to a general register.*
I read this as MOV Rd, Rs…
One more thing. In this code:
GetCurrentTime:
lCurrentTime = lTimerCnt + TCA
; handle wrap
if lTimerCnt <> (lCurrentTime & 0xffffff00) then
lCurrentTime = lTimerCnt + TCA
endif
return lCurrentTime
In my point of view, you’re doing the same thing twice here. So again, I might be overlooking something here.
And wat do you do with the 0xfffffff00 value?
Thanks again!
Xan
P.S. Learning C# will be a piece of cake for you if you have worked with other OO languages like C++. And the good think about C# is that it’s managed code. You don’t have to free memory Well, most of the time that is…
Now back to real world stuff. What I am trying to say is that if we can get the TA stuff working well, on a BAP28 with SSC-32, that would be great. A lot of people may want to trade off other functionality to get this. Things like:
.
.
