TA development topic

Let's Make Robots Project Ideas
41

Hi Xan,

The problem was you were reading the manual :laughing: What order the parameters come in unfortunately not consistent from processor to processor and as such often screws me up. I started off by looking at code and then the appendix with the instruction list. where luckily it says things like:
mov.b Rs, Rd (where s and d our source and destination…)

Now back to the get current time. Yep it is redundant. The reason why is that lCurrentTime = lTimerCnt + TCA is not an atomic operation. It may first move the variable lTimerCnt into a register and then move TCA into as well, which if I show an Assembly language version like:

mov.l @LTIMERCNT:16, er1 mov.b @TCA:8, r1l mov.l er1, @LCURRENTTIME
Note: this was typed on the fly and I may have missed something. Now suppose that the value of TCA was 0xff at the start of the first move (mov.l), and it increments to 00, which cause the timer to overflow and the interrupt is then processed. That is what the next If statement

if lTimerCnt <> (lCurrentTime & 0xffffff00) then

would catch and then rebuild the output again. There are alternative ways to do this, like to disable interrupts, compute the value, check the overflow flag in the status word and increment our counter…

The whole function in assembly language may look something like:

GetCurrentTime:
  ; 
  mov.l @LTIMERCNT:16, er1
  mov.l er1, er2
  mov.b @TCA:8, r1l
  mov.l er1, @LCURRENTTIME 
  cmp.l @LTIMERCNT:16, er2
  beq _GCT_NOOVF
  mov.l @LTIMERCNT:16, er1
  mov.b @TCA:8, r1l
_GCT_NOOVF:
 return lCurrentTime

Again typing from memory so probably missed something.
Kurt

42

Thanks. Having the line of code twice in there makes much more sense now :smiley:

43

I’ve got a few questions again…:

A. I’ve added the driver file into the project. The project does build but after the Linking part is gives the following error:
Error: Create Process failed.
Errors Detected
Have any of you seen this before? This error doesn’t say a thing so I have no idea where to look.

B. The XBEE module is connected to AUX1 P36 TX, P38 RX. Any suggestions on where to connect RTS since it needs a low voltage (3.3V)

C. Is it better to connect the SSC to AUX2 or can I use just any pin?

Thanks,

Xan

Edit: uploaded my working version
Working version.zip (51.9 KB)

44

Hi Xan,

Not sure about a) - I have seen that once or twice and I am not sure if low battery, or something screwy on the machine…

b) My guess is either P34 or P35 may have a lower voltage (SCL/SDA) as these are the two pins on BAP28 that are low…

c) SSC-32 should be able to go to any IO pins as we will be doing bitbang… I am 2/3’s the way hooked up and I left them on the same pins as it was on Bap28…

Kurt

45

Hi Kurt, Thanks for the quick reply!

A. I’ve got my ARC applied to net power so I don’t think it has anything to do with that.
When posted I forgot to attach the files. I updated my previous post with a zip file. If you have any spare time, could you check it out to see if you get the same result?

B. Sounds good, it there anything I could look for in the manual? I don’t want to blow up a xbee module :slight_smile:

C. P10 and P11 mixes up Zenta’s setup with the ARC only. I have to say that I already had to change the TA sensors since some wires where to short to get them connected. I leave them on in this way for now…

Thanks, Xan

46

I will give it a try today and let you know.

Yep, when I said 2/3 complete, I will still needing to connect up some of the sensors, Need to use some extension wires, I received in a previous care package…

My guess is if you are worried, you could probably put an inline resistor on the IO line. Don’t know for sure what size, but probably something around 300 would probably do the trick…

Kurt

47

I downloaded and it built fine on my machine.
Used Ram: 848, free 3248
Used Program total: 34804 free 21516…

Kurt

P.S. - I am using version 2.0.0.15 of studio.

48

2.0.0.13 here. Could be it… :slight_smile:

49

BTW: When I look at the H8/3687 manual all SCL pins say:
Can directly drive a bus by
NMOS open-drain output. When using this pin,
external pull-up resistance is required.
So it looks like they can be used directly for the RTS signal. Another thing I noticed in the manual is that no SCL pins say AUX1 or P34 like the ARC manual does. I think the pin numbers are remapped by the compiler. Do you know how to figure out which pin is what?

50

I pretty well know what pins are connected to what, due to a: their manual: downloads.basicmicro.com/downloa … _B0010.pdf

And my C Compiler library, where I do my own IO mapping, including all of the less than documented IO pins… Not that any of their stuff is overly documented :laughing:

BTW: For the fun of it, I took your sources and disabled GP (USEGP define in XBee file). I also extended that ifdef to core file, to conditionally not call the check if GP enable and GP code, and likewise the support code in the SSC-32 file. With these changes, I compiled this for Bap28.
Not much spare room: Program used total: 31734, Memory Free: 10 bytes.
But at least I know that once we get this working making a few more functionalities conditional, we should be able to get this to work on the Bap28. :smiley:

Kurt

51

2.0.0.15 Did the job. Thanks for pointing that out!
So we are compiling now… That’s a start :wink:

I’ve got the same sensor setup as Zenta:

cRRGCSPin con 19 ;Right Rear Ground Contact Switch cRMGCSPin con 18 ;Right Middle Ground Contact Switch cRFGCSPin con 17 ;Right Front Ground Contact Switch cLRGCSPin con 16 ;Left Rear Ground Contact Switch cLMGCSPin con 0 ;Left Middle Ground Contact Switch cLFGCSPin con 1 ;Left Front Ground Contact Switch
SSC:

cSSC_OUT con P11 ;Output pin for (SSC32 RX) cSSC_IN con P10 ;Input pin for (SSC32 TX)
XBEE:

XBEE_OUT con 38 ; (ARC Aux1 RX) To XBEE module Dout XBEE_IN con 36 ; (ARC Aux1 TX) To XBEE module Din XBEE_RTS con 34 ; (ARC Aux1 SCL) To XBEE module RTS

The comments say this about the XBEE configuration:

;------------------------------------------------------------------------------ ; [InitXbee] - Intializes the XBee - This function assumes that ; gosub InitXBee ; cXBEE_OUT - is the output pin for the Xbee ; cXBEE_IN - Is the input pin ; cXBEE_RTS - is the flow control pin. If using sparkfun regulated explorer ; be careful that this is P6 or P7 (for BAP28) as for lower voltage. DEFINED INT CONFIG FILE! ;------------------------------------------------------------------------------
I found that cXBEE_RTS can be defined in the config file. But there is no place where I can define Both XBEE_OUT and XBEE_IN pins. Also the constants cXBEE_OUT and cXBEE_IN are not used. Where can I define the XBEE pins?

I’ve been looking onto this manual to. But it only referrers to the pins on the PCB. I have no idea how to map them on the pin numbers of the H8/3687 manual that comes with the Basic Micro Studio.

For instance; if I look at figure 1.3 in the H8 manual I see that P57/SCL is located on pin 27 of the chip itself. But that is not pin 27 on the arc PCB. I know this because for example pin 9 of the chip is the VCC. This is can not be wired to I/O pin 9 on the PCB. I could not find a schematic or a ARC pin layout to figure this out…

Good! Do note that there currently is NO body IK solution in there at the moment. So we will need to disable more functionality to get this to fit.

That’s it for now. I’m stuck on the XBEE pins so it would be cool if you can clear this up for me :smiley:

Thanks,

Xan

52

First the quick answer: The XBee in/out pin constants are not needed as we are now using HSERIAL (in the Arc32 version HSERIAL2). So the actual pins are taken care of by the hardware. Should remove comments about those constants…

As for IO pins and mapping to underlying hardware, as I mentioned before I figured out, while I was working on C library. Nathan helped correct it in a few places.

Here is one of my tables for the Arc32:

[code]const PORTITEM g_PortTableArc32] =
{
{&IO.PDR5.BYTE, 0x10, {PUR_5, PMR_5, 0xf}}, // P0 servo0 (P54/WKP4)
{&IO.PDR5.BYTE, 0x20, {PUR_5, PMR_5, 0xf}}, // P1 servo1 (P55/WKP5/ADTRG)
{&IO.PDR1.BYTE, 0x1, {PUR_1, PMR_1, 0xf}}, // P2 servo2 (P10/TMOW)
{&IO.PDR1.BYTE, 0x2, {PUR_1,0, 0xf}}, // P3 servo3 (P11/PWM)
{&IO.PDR1.BYTE, 0x4, {PUR_1, PMR_1, 0xf}}, // P4 servo4 (P12)
{&IO.PDR7.BYTE, 0x20, {0,0, 0xf}}, // P5 servo5 (P75/TMCIV)
{&IO.PDR7.BYTE, 0x40, {0,0, 0xf}}, // P6 servo6 (P76/TMOV)
{&IO.PDR2.BYTE, 0x8, {0,0, 0xf}}, // P7 servo7 (P23)
{0,0,{0,0, 0xf}}, // P8
{0,0,{0,0, 0xf}}, // P9
{0,0,{0,0, 0xf}}, // P10
{0,0,{0,0, 0xf}}, // P11
{0,0,{0,0, 0xf}}, // P12
{0,0,{0,0, 0xf}}, // P13
{0,0,{0,0, 0xf}}, // P14
{0,0,{0,0, 0xf}}, // P15
{&IO.PDR5.BYTE, 0x8, {PUR_5, PMR_5, 0xf}}, // P16 servo16 (P53/WKP3)
{&IO.PDR5.BYTE, 0x4, {PUR_5, PMR_5, 0xf}}, // P17 servo17 (P52/WKP2)
{&IO.PDR5.BYTE, 0x2, {PUR_5, PMR_5, 0xf}}, // P18 servo18 (P51/WKP1)
{&IO.PDR5.BYTE, 0x1, {PUR_5, PMR_5, 0xf}}, // P19 servo19 (P50/WKP0)
{&IO.PDR3.BYTE, 0x1, {0,0, 0xf}}, // P20 servo20 (P30)
{&IO.PDR3.BYTE, 0x2, {0,0, 0xf}}, // P21 servo21 (P31)
{&IO.PDR3.BYTE, 0x4, {0,0, 0xf}}, // P22 servo22 (P32)
{&IO.PDR3.BYTE, 0x8, {0,0, 0xf}}, // P23 servo23 (P33)
{0,0,{0,0, 0xf}}, // P24
{0,0,{0,0, 0xf}}, // P25
{0,0,{0,0, 0xf}}, // P26
{0,0,{0,0, 0xf}}, // P27
{&IO.PDR1.BYTE, 0x80, {PUR_1, PMR_1, 0xf}}, // P28 servo28 (P17/IRQ3/TRGV)
{&IO.PDR1.BYTE, 0x40, {PUR_1, PMR_1, 0xf}}, // P29 servo29 (P16/IRQ2)
{&IO.PDR1.BYTE, 0x20, {PUR_1, PMR_1, 0xf}}, // P30 servo30 (P15/IRQ1/TMIB1)
{&IO.PDR1.BYTE, 0x10, {PUR_1, PMR_1, 0xf}}, // P31 servo41 (P14/IRQ0)
{&IO.PDR2.BYTE, 0x2, {0,0, 0xf}}, // S_IN (P32) (P22/RXD
{&IO.PDR2.BYTE, 0x4, {0,0, 0xf}}, // S_OUT TXD(P33) (P24/TXD)
{&IO.PDR5.BYTE, 0x80, {PUR_5, PMR_5, 0xf}}, // P34 AUX1 pin1 (P57/SCL)
{&IO.PDR5.BYTE, 0x40, {PUR_5, PMR_5, 0xf}}, // P35 AUX1 pin2 (P56/SDA)
{&IO.PDR7.BYTE, 0x4, {0,0, 0xf}}, // P36 AUX1 pin3 (P72/TXD_2)
{&IO.PDR7.BYTE, 0x1, {0,0, 0xf}}, // P37 AUX1 pin4 (P70/SCK3_2)
{&IO.PDR7.BYTE, 0x2, {0,0, 0xf}}, // P38 AUX1 pin5 (P71/RXD_2)
{&IO.PDR3.BYTE, 0x80, {0,0, 3}}, // P39 AUX1 pin6 (P37) and (PB3/AN3)
{&IO.PDR2.BYTE, 0x10, {0,0, 0xf}}, // P40 AUX2 pin2 (P24) with pullup
{&IO.PDR8.BYTE, 0x20, {0,0, 0xf}}, // P41 AUX2 pin4 (P85) with pullup
{&IO.PDR8.BYTE, 0x40, {0,0, 0xf}}, // P42 AUX2 pin6 (P86) with pullup
{&IO.PDR8.BYTE, 0x80, {0,0, 0xf}}, // P43 AUX2 pin8 (P87) with pullup
{&IO.PDR3.BYTE, 0x40, {0,0, 0xf}}, // P44 Status LED (P36)
{&IO.PDR7.BYTE, 0x10, {0,0, 0xf}}, // P45 Batt LED (P74/TMRIV)
{&IO.PDR3.BYTE, 0x10, {0,0, 0xf}}, // P46 MUX A (P34)
{&IO.PDR3.BYTE, 0x20, {0,0, 0xf}}, // P47 MUX B (P35)
{&IO.PDR6.BYTE, 0x1, {0,0, 0xf}}, // P48 U24 X (P60/FTIOA0)
{&IO.PDR6.BYTE, 0x2, {0,0, 0xf}}, // P49 U24 Y (P61/FTIOB0)
{&IO.PDR6.BYTE, 0x4, {0,0, 7}}, // P50 U21 X (P62/FTIOC0) (PB7/AN7)
{&IO.PDR6.BYTE, 0x8, {0,0, 6}}, // P51 U21 Y (P63/FTIOD0) (PB6/AN6)
{&IO.PDR6.BYTE, 0x10, {0,0, 0xf}}, // P52 U22 X (P64/FTIOA1)
{&IO.PDR6.BYTE, 0x20, {0,0, 0xf}}, // P53 U22 Y (P65/FTIOB1)
{&IO.PDR6.BYTE, 0x40, {0,0, 4}}, // P54 U23 Y (P66/FTIOC1) (PB4/AN4)
{&IO.PDR6.BYTE, 0x80, {0,0, 5}}, // P55 U23 X (P67/FTIOD1) (PB5/AN5)
{&IO.PDRB.BYTE, 0x1, {0,0, 0}}, // P56 VS1 (PB0/AN0)
{&IO.PDRB.BYTE, 0x2, {0,0, 1}}, // P57 VL (PB1/AN1)
{&IO.PDRB.BYTE, 0x4, {0,0, 2}}, // P58 VS2 (PB2/AN2)
{&IO.PDR7.BYTE, 0x20, {0,0, 0xf}}, // SCL
{&IO.PDR7.BYTE, 0x40, {0,0, 0xf}} // SDA
};

// How the MUXS are connected to the servos…
//Channel FTIOA0 FTIOB0 FTIOC0 FTIOD0 FTIOA1 FTIOB1 FTIOC1 FTIOD1
//0 2 7 10 15 18 20 28 25
//1 1 4 9 12 17 23 31 26
//2 0 6 8 14 16 21 29 27
//3 3 5 11 13 19 22 30 24
[/code]
As the table implies, not all Arc32 IO pins have an underlying H8 IO pin. Also note: there is some confusion issues with the actual IO pin numbers. If you look at the Arc32 manual, for example you will see P34 defined twice. Once it is defined as to get the voltage for S2, the other time it is defined as the SCL pin. Why? Because some of their commands map them differently… Personally I think that is bad, but…

Many of them are only connected through the MUXs. Also I have not double checked the code to check for Voltages. There is an interesting issue, that I have not done anything about yet. That is the command:
adin cVoltagePin, Voltage ; Battery voltage
Does not work on Arc32 you need to use the HSERVOSTATE command, that implies that HSERVO would have to be running… Unless maybe without HSERVO the adin command on one of the underlying voltage pins (P56-P58), which are actually hooked up to ADIN pins (not through MUX), may work…

Kurt

53

I forgot to mention that on all of the BAPs including the Arc32, there is a table that maps IO pins to the underlying Port and Pin. This is at the address: _PORTTABLE
This is used in some of my Assembly language functions like my own version of Serin/Serout… There are 2 bytes per IO pin here, one is the port address, the 2nd is the bit number within the port. So for example when I was generating the above table for Arc32, wrote a quick and dirty program that read this area and printed it out in hex.

Kurt

54

Hi Kurt,

Thanks for the table. I will save is somewhere. I know for sure it will come in handy from time to time.

Having the XBEE pins mapped by HSERIAL makes sense now. I think it’s good to update the comment on that. Zenta already pointed out that the XBEE module needs to be connected to AUX1 so I suggest that HSERIAL2 is mapped to AUX2.

I couldn’t get it to walk this weekend. Having no speaker makes is a bit harder since I can not hear the beep if I hit the on/off (0) button on the remote. So I do not know if I don’t get any data from the XBEE module, or if there is something wrong with the communication between the ARC and SSC. Is your THex already walking?

Xan

55

Sorry I was a bit lazy and have not tried yet. I was waiting until I knew for sure which IO pins you were using. I will later today. I have an appointment this morning, so it will have to be a bit later in the day. Yep speakers help.

HSerial2 is mapped to P36 and P38 which are on the AUX2 connector. It is also a shame that it is a cleaned up version of my normal code which has some #ifdef DEBUG type stuff that for example I could turn on displaying the XBee packets. May have to hack that back in to see what we are receiving… What Baud rate was this XBee init for? I believe the code is assuming 62500. Also it has been awhile since I tested using the RTS code, may need to check to see if the XBee connected on mine has one on it…

Kurt

56

That’s ok. I’m out for sports on Monday and Wednesday. I will not have time for this until tomorrow. :slight_smile:

Xan

57

Starting to play around and found some issues already…

If you look at the table I posted of the Arc32 pins, you will notice that P10 and P11 have no real IO pin associated with it. You can only use it for servo type things and analog voltages… So I will try moving:

cSSC_OUT con P21 ;Output pin for (SSC32 RX) cSSC_IN con P20 ;Input pin for (SSC32 TX) cSpeakerPin con P22
Will worry more about contacts after I get it up and running

Kurt

58

Hi Kurt,

I’m happy with you findings… I think…
I mean, it’s a big bummer the pins can not be used for as simple digital I/O. But at least I’m happy to know where to look. :slight_smile: I’m gonna give it a new try this evening!

Thanks, Xan

59

Yep, still working on it. So far my Arc32 with XBee is not talking… Not sure if it is the Arc32, Xbee or… These have been through a few previous battles, so it is possible I screwed one or more of them up. Now to start off with a simple XBee test program. May take the time to make a simple version that only uses Hserial (or Hserial2…)

Kurt

60

Hmm… I don’t like the sound of that… Keep me updated please!