How to efficiently send HM55B compass data to HyperTerminal

KickDaniel

Hello,

I'm working on a school project. We're trying to send compass data to be viewed on the HyperTerminal.

When we implement the given "Get_Compass_Axes" code, while the data is seen in the Basic Stamp editor Debug terminal, there is a great delay in the data printing out on the HyperTerminal. The delay is very inconsistent (from several seconds to minutes). Does anyone know how I can fix this?

Here is part of the code:

Collect:
DEBUG "Chose to collect data", CR
SEROUT 1,84,[noparse][[/noparse]"Please wait for the data.",CR]
GOSUB Compass_Get_Axes 'get x, and y values
angle = x ATN -y 'convert x and y to brads
angle = angle*/360 'convert brads to degrees
PAUSE 1000

DEBUG "x=", SDEC x,CLREOL,CR, "y=", SDEC y,CLREOL,CR, "angle=", DEC angle, " degrees",CLREOL,CR
PAUSE 1000
SEROUT 1,84,[noparse][[/noparse]"Here comes the data!",CR]
PAUSE 1000
SEROUT 1,84,[noparse][[/noparse]"Degree=",DEC angle," degrees",CR]
PAUSE 1000
..
..
..
Compass_Get_Axes: 'compass module subroutine

HIGH En : LOW En 'send reset command to HM55B
SHIFTOUT DinDout, clk, MSBFIRST,[noparse][[/noparse]Reset\4]

HIGH En: LOW En 'HM55B start measurement command
SHIFTOUT DinDout, clk, MSBFIRST,[noparse][[/noparse]Measure\4]
status=0 'clear previous status flags

DO 'status flag checking loop
HIGH En: LOW En 'measurement status command
SHIFTOUT DinDout, clk, MSBFIRST,[noparse][[/noparse]Report\4]
SHIFTIN DinDout,clk,MSBPOST,[noparse][[/noparse]Status\4] 'get status

LOOP UNTIL status = Ready 'exit loop when status is ready

SHIFTIN DinDout,clk,MSBPOST,[noparse][[/noparse]x\11,y\11] 'get x and y axis values
HIGH En 'disable module

IF (y.BIT10 = 1)THEN y=y|NegMask 'store 11-bits as signed word
IF (x.BIT10 =1)THEN x=x|NegMask 'repeat for other axis
RETURN


Thank you in advance! Any tips would be greatly appreciated.

Bruce Bates

KickDaniel -

Try removing the PAUSE statements between the SEROUT commands.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming can't be all that difficult, it's nothing but 1's and 0's

KickDaniel

Hi Bruce,

Thanks for your reply. Unfortunately, it doesn't solve the problem.

Daniel

Bruce Bates

Daniel -

If you'd like more assistance "it doesn't solve the problem" doesn't help us very much. Since I doubt it runs any slower than before, perhaps you could describe any new symptoms, or problems?

It would also be a big help, if you attached a copy of the complete program, so we can see the entire picture. Use the Attachment Manager to upload your program.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming can't be all that difficult, it's nothing but 1's and 0's

Post Edited (Bruce Bates) : 3/13/2008 4:33:01 AM GMT

KickDaniel

Hi Bruce,

Ah, sorry about that. All the debugging has been a frustrating process.

The delay is very inconsistent, so it is very hard to compare. By taking out those pauses, the code runs a couple seconds faster, but the data still takes a very long time to get to the HyperTerminal.

Also, by clicking 'disconnect' & then 'connect' in the HyperTerminal, the compass data finally shows up, and then proceeds through with the rest of the code -- as if everything picked up from the line, SEROUT 1,84,[noparse][[/noparse]"Degree=.....].

Please let me know if you'd like more specifics. Thanks so much for your feedback.

Daniel

Franklin

Does the debug terminal update every few seconds even though the data does not go to hyperterminal?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

KickDaniel

Hi Stephen,

Yes, the debug terminal shows x, y, and angle properly. And strangely, as you said, the debug terminal updates every few seconds. After going through the collect function without carrying out the SEROUT parts, the code returns to the main block, which is supposed to ask the user what he/she wants to do with another SEROUT.. but instead, it goes through this code and past the 'IF' statements and goes directly into the Collect function again (effectively looping until the compass data is finally printed on the HyperTerminal).

Daniel

Bruce Bates

Daniel -

And I REPEAT:

"It would also be a big help, if you attached a copy of the complete program, so we can see the entire picture. Use the Attachment Manager to upload your program."

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming can't be all that difficult, it's nothing but 1's and 0's

KickDaniel

Hi Bruce,

Sorry about that.

Daniel

Bruce Bates

Daniel -

It would have been helpful if somewhere along the line you would have mentioned that there was an EB500 RF link between the programming board, and Hyperterminal on your computer.

I suspect the delay lies there, but I also suspect that's not all there is to it. Unless I miss my guess, you will probably have to use flow control (See SERIN/SEROUT in the PBASIC Help File). Usually flow control requires extra pin ports, if the EB500 supports it. I don't know since I've never gotten involved with the EB500.

I don't know that it matters, the above being considered, but a mention of the PING would have been nice too. That too can cause time delays, although I didn't look to see if it was causing any such delays in your program.

If that's not the cause, we'll go from there.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming can't be all that difficult, it's nothing but 1's and 0's

KickDaniel

Hi Bruce,

Thanks for your suggestions and advice. I've been reading up on the SEROUT/SERIN commands.

Turns out the data collected prints onto the HyperTerminal more consistently (4 to 20 seconds) when I add in pauses in the Get_Compass_Axes window after SHIFTIN commands (see below), whereas before it could be anywhere from 4 to 2 minutes.

It seems this gives the basic stamp time to process the data? Would you know why these pauses are helping?

Everything is the same except the following (the pauses):

Compass_Get_Axes: 'compass module subroutine

HIGH En : LOW En 'send reset command to HM55B
SHIFTOUT DinDout, clk, MSBFIRST,[noparse][[/noparse]Reset\4]
PAUSE 300

HIGH En: LOW En 'HM55B start measurement command
SHIFTOUT DinDout, clk, MSBFIRST,[noparse][[/noparse]Measure\4]
status=0 'clear previous status flags
PAUSE 300

DO 'status flag checking loop
HIGH En: LOW En 'measurement status command
SHIFTOUT DinDout, clk, MSBFIRST,[noparse][[/noparse]Report\4]
PAUSE 1000
SHIFTIN DinDout,clk,MSBPOST,[noparse][[/noparse]Status\4] 'get status
PAUSE 300
LOOP UNTIL status = Ready 'exit loop when status is ready

SHIFTIN DinDout,clk,MSBPOST,[noparse][[/noparse]x\11,y\11] 'get x and y axis values
PAUSE 300
HIGH En 'disable module

IF (y.BIT10 = 1)THEN y=y|NegMask 'store 11-bits as signed word
IF (x.BIT10 =1)THEN x=x|NegMask 'repeat for other axis
RETURN

Thanks much,
Daniel

Bruce Bates

Daniel -

First, I'm completely puzzled why PAUSE statements should make anything run FASTER. PAUSE does what its name implies, it simply pauses. However, I can see one area where pauses may be clobbering the time element.

Second, PBASIC commands are completed before the program can even continue. That should have no significant effect on the time element.

Have you ever tried absolutely NO pauses, anywhere in the Get_Compass_Axes routines? If not, I'd comment out ALL the pauses therein, and give it a try. ALSO, while you're at it, just for this test, comment out any DEBUG statements that may be in those routines as well. They can be changed later.

Let us know how you make out with this test. We're getting somewhere, honestly, it just take a bit of patience

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming can't be all that difficult, it's nothing but 1's and 0's

KickDaniel

Hi Bruce,

The program I had before, which gave me a long delay time (4 to 2 minutes) was with NO pauses in the Get_Compass_Axes routine. After I added the pauses within that sub-function, the program ran faster (4 to 20 seconds). My question is why this is.

It's hard to tell if the DEBUG statements are making a big difference in the timing. I've tried it with and without the DEBUG statements in there and it isn't a very noticeable delay.

So what do you think?

Thanks,
Daniel

Bruce Bates

Daniel -

We're not working with any program other than the one you recently supplied. How another unseen program worked or didn't work is beyond the abilities of my crystal ball.

I don't have a compass module. I have an idea where the problem might be. If you don't want to remove the pauses for TESTING, the I guess someone else will have to help you. Sorry.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming can't be all that difficult, it's nothing but 1's and 0's