Daughter board for Gumstix-new questions.
Daughter board for Gumstix-new questions.
by clusher
Sun Jun 07, 2009 8:29 pm
Hey all.
For those who don't know, I'm trying to make up a daughter board to connect the gumstix to an ATXmega128 and the microprocessor to different buses, connected to the AX-12 of the Bioloid.
We've been worrying about a lot about the components and we may have overlooked one or two problems. Right now, we're dealing with the connection from the ATXMega to the Bioloid bus.
The UART's from ATX don't have a pin that we can use for direction bit. So we decided to use the same components that are shown on the AX-12 manual, but instead of using a direction bit, we simply connect them to 5V and we rely on the software to make sure the Atx stops sending info until a reply is received from the servos. Is this ok? And can it be done using open collectors?
Thanks in advance, I know I'll get some good answers :p
For those who don't know, I'm trying to make up a daughter board to connect the gumstix to an ATXmega128 and the microprocessor to different buses, connected to the AX-12 of the Bioloid.
We've been worrying about a lot about the components and we may have overlooked one or two problems. Right now, we're dealing with the connection from the ATXMega to the Bioloid bus.
The UART's from ATX don't have a pin that we can use for direction bit. So we decided to use the same components that are shown on the AX-12 manual, but instead of using a direction bit, we simply connect them to 5V and we rely on the software to make sure the Atx stops sending info until a reply is received from the servos. Is this ok? And can it be done using open collectors?
Thanks in advance, I know I'll get some good answers :p
by clusher
Mon Jun 08, 2009 10:29 am
The thing is that I'm using all 6 UART's to connect to 6 different buses... so there are no IO pins that I can write to in order to control the communications direction.
The way I'm doing now makes that the reading pin is always receiving (this means it receives all the AX-12 messages as well as everything he himself sends) because the receiving buffer is always on. Why do you say it prevents atx from receiving the AX-12 communications?
Our main concer is if there's a real chance of short circuiting the board and if we can use open collectors instead of regular buffers.
EDIT: Nevermind all that. We really are newbies on this microprocessor programming. We do want to use other general pins as a direction bit. A new questions rises: we define that 3 Ports are to be used as 6 UARTs, and this leaves a few pins of each port without any function. Can these be used as direction? Or do we need to use pins from another Port?
What I mean is: for example, there is the PORTC, with 10 pins. 2 pins are VCC and GND. 6 pins are CLK, RXD and TXD of two UARTs. This leaves 2 pins that have no function. Can these be used as direction?
The way I'm doing now makes that the reading pin is always receiving (this means it receives all the AX-12 messages as well as everything he himself sends) because the receiving buffer is always on. Why do you say it prevents atx from receiving the AX-12 communications?
Our main concer is if there's a real chance of short circuiting the board and if we can use open collectors instead of regular buffers.
EDIT: Nevermind all that. We really are newbies on this microprocessor programming. We do want to use other general pins as a direction bit. A new questions rises: we define that 3 Ports are to be used as 6 UARTs, and this leaves a few pins of each port without any function. Can these be used as direction? Or do we need to use pins from another Port?
What I mean is: for example, there is the PORTC, with 10 pins. 2 pins are VCC and GND. 6 pins are CLK, RXD and TXD of two UARTs. This leaves 2 pins that have no function. Can these be used as direction?
by i-Bot
Mon Jun 08, 2009 4:01 pm
The buffers do help the chip to drive longer cables and to protect the processor, so best to include them. Also Tristate is preffered to open collector for driving longer cables and is more noise resistant.
I would suggest you keep the buffers into the XMega receive enabled all the time and disable in software when you are transmitting. Be carefull to re-enable after the last byte is sent from the Xmega, not just when you loaded the last byte to be sent, use TX complete for this not TX data register empty.
Then use the Usart XCK pin or any other I/O pin to control the enable of the buffer out from the XMega. XCK is available because you will be using internal clock and the XCK pin is not needed by the USART, so available for general purpose I/O.
If this configuration does not suit you, we can find another, the XMega looks very flexible in its configuration, though that is probably also the source of the confusion.
I would suggest you keep the buffers into the XMega receive enabled all the time and disable in software when you are transmitting. Be carefull to re-enable after the last byte is sent from the Xmega, not just when you loaded the last byte to be sent, use TX complete for this not TX data register empty.
Then use the Usart XCK pin or any other I/O pin to control the enable of the buffer out from the XMega. XCK is available because you will be using internal clock and the XCK pin is not needed by the USART, so available for general purpose I/O.
If this configuration does not suit you, we can find another, the XMega looks very flexible in its configuration, though that is probably also the source of the confusion.
by limor
Mon Jun 08, 2009 4:37 pm
Hi clusher
which gumstix version are you looking at?
i'm always on the lookout for anything that will help get better closed-loop-control for the bioloid bus. what i like about the the Xmega series and their many UARTs is the potential to split the Bioloid bus into several independent portions. sub-bus gets fewer servos allowing send-receive packet cycles of 150/sec instead of <50.
so if closed loop control is what you are after, then i would recommend using 5 of 6 UARTs to control 5 independent Bioloid buses and 1 UART to communicate with the Gumstix. The Dynamixel protocol is inneficient enough that 5 UARTs running the 1mbps Dynamixel protocol can probably be compressed (for the purpose of closed loop control) into a single 900kbps talking to the gumstix.
any chance you can post the schematics ?
which gumstix version are you looking at?
i'm always on the lookout for anything that will help get better closed-loop-control for the bioloid bus. what i like about the the Xmega series and their many UARTs is the potential to split the Bioloid bus into several independent portions. sub-bus gets fewer servos allowing send-receive packet cycles of 150/sec instead of <50.
so if closed loop control is what you are after, then i would recommend using 5 of 6 UARTs to control 5 independent Bioloid buses and 1 UART to communicate with the Gumstix. The Dynamixel protocol is inneficient enough that 5 UARTs running the 1mbps Dynamixel protocol can probably be compressed (for the purpose of closed loop control) into a single 900kbps talking to the gumstix.
any chance you can post the schematics ?
by clusher
Mon Jun 08, 2009 4:56 pm
@i-bot: I just wasn´t sure if the XCK bit could be software controled. We are looking at open colector because the AtxMega uses 3.3V and the AX-12 only recognizes HIGH at 5V. This means that if we use the tristate buffers, we also have to convert from 3.3V logic to 5V... with open collector this would not be a problem. However, we still need to see if we can maintain 1Mbps communications with open collector, because if not then weare back at directional bit!
@limor: we are using the gumstix verdex (you know... the IST group at Portugal). We are using 6UARTs to communicate with the servos and 1 UART for the GumStix. I don't have the most recent designs, I'll ask to my partner. We are expecting to be able to compress the Dynamixel enough to make this efficient. Plus, the Bioloid now has the 6Axis IMU from huvrobotics (I'm considering reserving one bus for it alone) and there are plans to make contact or pressure sensors for the feet.
The general idea would be to distribute the buses as 1.IMU 2 and 3. Arms 4. Hip zone 5 and 6. Legs
@limor: we are using the gumstix verdex (you know... the IST group at Portugal). We are using 6UARTs to communicate with the servos and 1 UART for the GumStix. I don't have the most recent designs, I'll ask to my partner. We are expecting to be able to compress the Dynamixel enough to make this efficient. Plus, the Bioloid now has the 6Axis IMU from huvrobotics (I'm considering reserving one bus for it alone) and there are plans to make contact or pressure sensors for the feet.
The general idea would be to distribute the buses as 1.IMU 2 and 3. Arms 4. Hip zone 5 and 6. Legs
by i-Bot
Tue Jun 09, 2009 1:00 am
I have not used the XMega, and was surprised that the I/O are not 5V tolerant. I am using the AVR32 and they are.
The AX12 use HC logic, so do need 5V CMOS levels
I suggest to still avoid open collector if possible at these data rates on servo wires.
How about to use different devices for Transmit and receive. For transmit you need a 5V CMOS logic family with TTL compatible inputs. These will take input from 3.3V logic OK. This should be powered from 5V. Like a 74HCT126.
For receive use a 3.3V CMOS logic family with 5V tolerant inputs, like the 74LVC126. Power this from 3.3V
The AX12 use HC logic, so do need 5V CMOS levels
I suggest to still avoid open collector if possible at these data rates on servo wires.
How about to use different devices for Transmit and receive. For transmit you need a 5V CMOS logic family with TTL compatible inputs. These will take input from 3.3V logic OK. This should be powered from 5V. Like a 74HCT126.
For receive use a 3.3V CMOS logic family with 5V tolerant inputs, like the 74LVC126. Power this from 3.3V
by ricardocrl
Tue Jun 09, 2009 1:03 am
Hi guys,
I am the partner of clusher. I'm a student with not much knowledge trying to help in this project. I'm really newbie in all this matters, microprocessors, electronics, and so on. So... go slow if possible when explaining things.
In order to solve this incompatibility of power supply (3.6v -> 5v) we thought of Logic Level Translator from Maxim. I saw this one: MAX3003 - http://datasheets.maxim-ic.com/en/ds/MA ... AX3012.pdf. It has an enable pin (EN A/B) to switch from active mode of A lines(I/O) to B lines, having 4 of each. What about using this, just choosing to receive or to transfer data (all buses at the same time)? A's receiving and B's transfering, for example.
I think this would solve: the different logic level problem, the enables inverted for receiving/transferring, reduces the I/O pins to control and uses few components in the board.
I am the partner of clusher. I'm a student with not much knowledge trying to help in this project. I'm really newbie in all this matters, microprocessors, electronics, and so on. So... go slow if possible when explaining things.
In order to solve this incompatibility of power supply (3.6v -> 5v) we thought of Logic Level Translator from Maxim. I saw this one: MAX3003 - http://datasheets.maxim-ic.com/en/ds/MA ... AX3012.pdf. It has an enable pin (EN A/B) to switch from active mode of A lines(I/O) to B lines, having 4 of each. What about using this, just choosing to receive or to transfer data (all buses at the same time)? A's receiving and B's transfering, for example.
I think this would solve: the different logic level problem, the enables inverted for receiving/transferring, reduces the I/O pins to control and uses few components in the board.
by i-Bot
Tue Jun 09, 2009 2:18 am
This Maxim device looks like it will work, though I think that seperate direction control of each bus would be better, and maybe easier on the software.
From a cost perspective the Maxim device is more expensive, though in very small quantity (< 4) is lowest cost due to the Maxim generous and responsive samples policy.
Also I am not sure if you are making a PC board, package is also a consideration.
From a cost perspective the Maxim device is more expensive, though in very small quantity (< 4) is lowest cost due to the Maxim generous and responsive samples policy.
Also I am not sure if you are making a PC board, package is also a consideration.
by ricardocrl
Tue Jun 09, 2009 10:38 am
Also I am not sure if you are making a PC board, package is also a consideration.
Yes, we were looking at DIL packages, not SMD, in order to use sockets to change it if something goes wrong. I don't actually find any not SMD of this max3003.
Anyway, with so many issues it seems to me that once we get a solution we won't bother with the package... But I'll have to confirm it with our professor.
To have one enable per line, I just see IC with only one line and 6 pins each (V_I, V_O, VL, VCC, GND, EN). This requires 12 IC of 6 pins and I think it's a lot of space in our board! :\
by clusher
Thu Jun 18, 2009 12:46 pm
Hey guys, new question.
So, our professor asked us to make a little experiment in order to measure the rise time using open collectors and not using them. The idea is to measure a rise time from the DATA pin of the AX-12 BUS using an osciloscope.
There I went, making a simple C program that would allow me to manipulate the PE1 pin to HIGH and LOW. The thing is, it doesn't work. I enabled the TxD mode, and then I made a small program to pull the pin HIGH and LOW... It gives a really strange signal... Am I doing it right?
So, our professor asked us to make a little experiment in order to measure the rise time using open collectors and not using them. The idea is to measure a rise time from the DATA pin of the AX-12 BUS using an osciloscope.
There I went, making a simple C program that would allow me to manipulate the PE1 pin to HIGH and LOW. The thing is, it doesn't work. I enabled the TxD mode, and then I made a small program to pull the pin HIGH and LOW... It gives a really strange signal... Am I doing it right?
by i-Bot
Thu Jun 18, 2009 3:28 pm
It is not clear how you are trying to use PE1. PE1 can be used as UART TX or as general purpose output. You say your are driving high and low which suggest general purpose, but say you enable TX which suggests UART.
Depending on which it is make sure the configuration registers are then set correct
Depending on which it is make sure the configuration registers are then set correct
by i-Bot
Thu Jun 18, 2009 11:30 pm
The Xmega is more flexible an hence more complex tan the ATMega which I have used.
If you look at the data sheet, then the alternate function (UART) can override the GPIO, so do not enable the UART. Port PE1 is TX out on the ATMega, but not on the XMega, this would be port PE3.
Take regard to the different datasheets for XMega A, XMega128-A1, and the ATMega128
Work only with the I/O port registers. For Port E these are 32 registers located at peripheral address starting 0x0680 (datasheet section 31) and are defined in datasheet section 13.17
Assuming you work with PE1, then you must consider the DIR direction register to set PE1 as output, then use the OUT register to set and clear the bit, or alternatively use the set/clear/toggle.
Consider the setting of the PIN1CTRL for the mode you want to experiment with.
If you look at the data sheet, then the alternate function (UART) can override the GPIO, so do not enable the UART. Port PE1 is TX out on the ATMega, but not on the XMega, this would be port PE3.
Take regard to the different datasheets for XMega A, XMega128-A1, and the ATMega128
Work only with the I/O port registers. For Port E these are 32 registers located at peripheral address starting 0x0680 (datasheet section 31) and are defined in datasheet section 13.17
Assuming you work with PE1, then you must consider the DIR direction register to set PE1 as output, then use the OUT register to set and clear the bit, or alternatively use the set/clear/toggle.
Consider the setting of the PIN1CTRL for the mode you want to experiment with.