Interfacing problem with Basic Stamp BS2px24 and LM629

Kwang

I had tried to interface the·BS2px24 to a LM629 for the past two weeks but still cannot get it to work.
Datasheet & Application Notes for LM629 seems too vague.

Can anyone advise how to do it?

Thanks in advance.

1)Is there a logic level mismatch between the BS2px24 and LM629?
2)Can a direct connection between BS2px24 and LM629 works? Or do I need interfacing components?
3)I had connected 8 pins from BS2px24 to LM629 as databus, 5 pins as control bus (CS,PS,RD,WR,RST). Initialize·CS,PS,RD,WR and RST to high.·However, pulling CS,PS and RD to low (for RDSTAT) does not seems to work.·Listened to the databus, but there was no reply. All zero.
4)As BS2px24 does not have function to tap the internal clock signals for synchronising with the LM629, can an external clock connected directly to LM629 work then? I thought the clock is used mostly by the encoder.
5)Do I need to synchronise the data transfer betwwen BS2px24 and LM629?
6)What logic level is LM629 working in TTL, CMOS, LVTTL, etc?

Bruce Bates

Kwang -

This chip is designed to be used with at least a 16-bit PARALLEL bus, and thus you will probably continue to have problems with the interface. I have attached the LM628/629 Users Guide for you inspection.

Regards,

Bruce Bates

Kwang

Hi Bruce,

· First of all, thanks for the reply.

· So, would·u recommend that I try with BS2p40 as it has 32 I/O pins for use or would u suggest that I seek an alternative microcontroller? The user guide was not very clear with the interfacing.



Rgds,

Kwang

Bruce Bates

Kwang -

Personally, I've had better success with devices that DO NOT use a bus structure. The PBASIC Stamp was never designed to work easily with bus structures.

I've always had good luck with motor controllers like the L298, but you've not been all that specific about your exact needs. Many successful projects have used the L298 and similar motor control chips.

I have attached a copy of the L298-D chip for your inspection.

Regards,

Bruce Bates

Mike Green

Not having worked with the device (LM629), I can't make specific recommendations, but it ought to work with a Stamp. The signals are straightforward, should be Stamp compatible. CS and PS should be set first (CS low, PS depending on status/data), then RD should be brought low, then the data lines read just before RD is brought high. To make things easiest, you should attach the data lines to either P0-P7 or P8-P15 so you can use byte references for the I/O pins (INL or INH, OUTL or OUTH). For writes, set CS and PS first, then set WR low, output the data, then bring WR high and then change the data pins to INPUT again. Don't forget that the direction bits have to be set properly and that I/O will be slow. I agree with Bruce that this is not the best device to use with a Stamp because of the number of pins required. If you still want to use a Stamp, the BS2p40 is a better choice because of the extra I/O pins.

Here, data is pins 0-7, cs is pin 8, ps is pin 9, rd is pin 10, and wr is pin 11

DIRL = %00000000 ' data bus is input
OUTC = %1111 ' initialize control lines to high
DIRC = %1111 ' make them outputs
;
OUTC = %1100 ' cs and ps low
OUTC = %1000 ' wr low as well
info = INL ' data should be ready here (< 1us needed)
OUTC = %1100 ' wr high
OUTC = %1111 ' other lines high

Kwang

Source Code
========
' {$STAMP BS2px}
' {$PBASIC 2.5}

StatusByte VAR Byte

Main:
GOSUB Init ' Initialization
GOSUB HW_RST ' Hardware Reset
END

Init:
DEBUG "-INIT

---

", CR
DEBUG "PIN# : 5432109876543210", CR

'Initialize the pins to high first since they are active high triggered
DIRH = %00000000 ' databus P8-P15 is input
OUTA = %1111 ' initialize control lines to high, P0=PS, P1=WR, P2=CS, P3=RD
DIRA = %1111 ' make them outputs
OUT4 = %1 ' set the RST pin high
DIR4 = %1 ' make RST pin as output pin
DEBUG "I/O : ", BIN16 INS, CR
DEBUG "-\INIT

---

", CR
Return

HWRST:
DO
OUT4 = %0 'RST Low
PAUSE 1 'min 8 clock cycles, assume 1ms is sufficient
OUT4 = %1 'RST High
GOSUB RDSTAT
LOOP UNTIL (StatusByte = $C4 OR StatusByte = $84)
RETURN

RDSTAT:
OUTA = %1010 'CS and PS Low
OUTA = %0010 'RD low
StatusByte = INH 'Read databus P8-P15
OUTA = %1010 'RD high
OUTA = %1111 'CS and PS High
DEBUG " Status: ", BIN8 StatusByte, " (", HEX2 StatusByte, ")", CR
RETURN

Ouput on Screen
=========================
-INIT

---

PIN# : 5432109876543210
I/O : 0000000000011111
-\INIT

---

Status: 00100001 (21)
Status: 00100000 (20)
Status: 00100000 (20)
Status: 00100000 (20)
Status: 00100000 (20)
Status: 00100000 (20)
Status: 00100000 (20)
Status: 00100000 (20)
Status: 00100000 (20)
Status: 00100000 (20)
Status: 00100000 (20)
Status: 00100000 (20)
Status: 00100000 (20)
Status: 00100000 (20)
Status: 00100000 (20)
Status: 00100000 (20)
Status: 00100000 (20)
Status: 00100000 (20)
Status: 00100000 (20)
Status: 00100000 (20)

The data returned by LM629 seems to be fixed after reset is sent. As shown by the status, it is staying at hex20. Sometimes, it jump to maybe hex00 or hex30.

I did not attached a clock to the CLK input pin of LM629 in this example though. I was thinking that the RST is an asychronous input and so might not need a clock as long as I pause long enough, correct me if I am wrong in this line of thought.

If I were to connect a 8Mhz clock and power up, then the return status byte would be FF.

LoopyByteloose

By the way, the Propeller can handle 16 bits wide or possilby even 32 [noparse][[/noparse]with some I/O pin limitations due to sharing 4 pins].

Since the Propeller chip is competatively priced with the BasicStamps, it may be a better fit. You certainly will have more speed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········

···················· Tropical regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Kwang

The propeller sure look powerful but is the coding difficult? Will consider this as one of the option if the learning curve is not that steep and development time is short.

Still, I was wondering what is preventing the stamp from communicating effectively with the motor controller.
Tried various means and even different clocks circuits, still doesn't seems to work out. How could I better troubleshoot the problem?

Hmm... perhaps, I should skip the step of resetting LM629 and jump straight to writting some command byte and data byte and see how the status byte change in response.

LoopyByteloose

SPIN is not that difficult. It is an OOP {Object Oriented Programing Language] and the IDE is quite user friendly [noparse][[/noparse]more than PBASIC]. Nearly everything in PBasic has be ported over to SPIN as an Object.

As long as you don't 'fall in love' with video processing, things would be quite similar to programming in PBasic.

If you look at the 8 COGs, they each have a Video Processing unit. After you get the hang of it, you might want the video and keyboard interface [noparse][[/noparse]and/or mouse] for some projects. That is where you might find a steep learning curve. Right now, I am trying to comprend how the video juggles memory with something referred to as tiles. Apparently the tiles are just handled like strings of text [noparse][[/noparse]and in fact they can be strings of text].

You can buy the chip set [noparse]/noparse]about $15-20 with Xtal, EEPROM, regulator, Level Shifter [noparse][[/noparse]or a few transistors and create your own board or buy the PropStick if you can afford the extra cost.

I am sure it will be a rewarding addition.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········

···················· Tropical regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Post Edited (Kramer) : 12/28/2006 9:47:07 AM GMT

Kwang

Design Requirement for my part.
1) Need motion control
2) Need to drive more than 3 Ampere motors continuous, maybe around 6A continuous. 18 to 24VDC.

- The datasheet for LM629 seems to be saying that it needs 8bits for datapins and 6bits for control pins(CS,PS,RD,WR,RST,HI), is that what makes up the 16bit parallel bus requirement?
- If LM629 requires a 16bit Parallel bus and I go with a SX28BD or SX48BD instead, will it work with the interface? Must I go with a micro-P capable of working 16bit wide bus? Or during the micro-P selection, I have to go with one based on a 16bit core.
- L293 can only deliver 600mA, not sufficient to provide the power. Internet is down due to Taiwan Earthquake...!!! difficulty accessing L298 datasheet, can someone provide here? Is it able to drive >3A?

Bought a new LM629 and retested, it seems to be working fine and gave the response $C4 initially but it could not perform a RSTI properlly and cannot return $C0 or $80. Then, I ignored the condition and proceed to try and load in all the filters and trajectory parametes and after some time time later, it seems to revert back to $$FF again all the time. Did I caused something to locked up along the process.

Checked on the 8Mhz clock on the oscilloscope and it gives a pretty nice clocking, no problem with clock.

Last thing, if Basic Stamp can sink and source about 30~40mA of current for each I/O pins but LM629 datasheet shows that the input pins current is between -10microAmpere to 10microAmpere. Will there be a problem. Am I killing the LM629 by directly connecting the basic stamp to LM629 data and control pins?

I know there is too many questions here. Please bear with me and help me solve the problem. Thanks.

LoopyByteloose

I am in Taiwan too. I cannot answer all your questions, but here are some answers.

Yes, it appears that not all of the 16bits are used. My count is 13 total. So those unused bits would be ignored.
You can either build a 16bit wide output with two bytes or go with a 16bit or 32bit processor.

While the SXes will tolerate 30ma, less is better. The whole uP can only withstand 130ma at one time. I don't think direct connection will cause any problem if all the pins are TTL or CMOS logic interface.

The Propeller supports a 32bit LONG, but can divide it into 16bit WORDS or 8bit BYTES.
The Propeller also has 32 I/O pins available.
So you get more speed and simpler code.
The Propeller is a 3.3volt system, so you have to provide a 2nd regulator. It will tolerate 5.0 volt I/O.

On the other hand, the SX28 and SX48 need to build a 16bit WORD from two BYTES.
It can be done, but twice as slow at the same clock speed.
It is the same problem as the BasicStamp2px.
And in some cases, you might need a 16bit latch to get the timing right.
The SX28 has only 20 I/O pins available.

The L298 is a much simpler device to control,only 6 i/o pins - rated 4amps from 6 to 26 volts DC.
Try www.solorbotics.com for a complete kit if that is your choice.
But, it is not as precise a controller as the LM629.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········

···················· Tropical regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Kwang

Thanks for the reply. So the reason you are trying to recommend 32bit Propeller over 8-bit Stamp is because with 8-bit Stamp, it is not fast enough to be compatible with the faster LM629 that work better with 16-bit micro-P. And this is probably the reason why I can't seems to get the thing working? The speed is most likely not matching.

I suspect I actually cooked the LM629, but no smell and sign of being cooked. How do I identify if the IC is burnt or not? LM629 is still giving a response, just not the one I expect. Always giving $FF if I had the clock signals inputted to the CLK pin OR $00 if there is no clock signals supplied. Did I really kill the IC, or did I not?

I'm not in Taiwan, but the internet access here is greatly affected in some way. A lot of website simply timeout or inaccessible. Heard that 6 of the 8 fiber optic underwater channels were damaged. Nature is really messing things up this time.

I managed to find a pc with a faster internet access (not through the phone line) and looked at the datasheet for L298. It does not seems to be the one I need. It is only providing a brige ciruit like a LMD18201, but no motion control in place. That's the reason why I insist on sticking with LM629. It is really fustrating to be working on something for a few weeks and then find that it does not work out. Hai... my skills are still not up to it.

Kwang

The previous LM629 seems dead. Changed to a new LM629 and added a clock of 8MHz. Managed to get a response of $C4 after a hardware reset. Also, managed to get a response of $C0 or $80 after a RSTI command. So, a clock is necessary for LM629 to function. My advise to anyone: Use a Logic Analyser to understand the actual timing, then adjust the timing through tweaking the PBasic coding in the basic stamp. It is crazy to depend only on oscilloscope and try to imagine what is actually happening. I had spent months on it by now.

I then proceed to connect a LMD18201 to the LM629 and a brushless dc motor with no encoder to the LMD18201.

Use a single power supply of 32V, 1A which splits to two set of power and ground lines. On one set, drop the voltage to 5V through 2 stages of voltage regulators (24V, then 5V). This set supplies to the basic stamp BS2px24 and LMD18201. On the other set, drop the voltage to 24V with one voltage regulators. This one supplies to the LMD18201. After connecting all the parts, I powered on the system.

Initially seems a little ok, , but after a couple of runs the nightmare seems to reappear. LM629 started returning with $FF agains. What is wrong here? Did I killed LM629 because I connected a motor and power up?

Can someone explain what are the possibilities and the reason that explains why after connecting a motor, LM629 can get killed instead?

1) Is it that I should not use a common power supply? Should I use two separate power supply for powering ICs and motor?
2) How is it possible that LM629 gets killed in this way?
3) How come Basic Stamp BS2px24 or LMD18201 was not killed in this way?
4) How can I protect LM629 not getting killed? Was it some back EMF issue here?

Really need to get this whole system·working.

Rgds,
Ming Siong.