does the Bs2 work faster when it is not hooked up to board of education

yoda152

hi all

i have my project fully progamed and ready to go, but i run into a problem when (linked up to the computer) i run the program it takes some time to excecute some of the tasks even though i have no pauses in the program. does the bs2 work faster when it is not hooked up to the education board hence it is on a board that you would put it on for the purpose inteneded? (it is working for the job inteneded)

regards

Zoot

Do you have DEBUG statements in your program?

yoda152

yes i have DEBUG statments in my program. do you have any advice for speeding it up for the real opperation. should i talk out all DEBUG statments?

Mike G

Yes removing the DEBUG statements will increase execution.

do you have any advice for speeding it up for the real opperation

Post your code.

Zoot

Mike G is right. DEBUGs should be removed if they are not required for the program to run. Every character you send out via DEBUG slows your program time way down. The Baud rate on DEBUGs is relatively slow and the time for the Stamp to execute the DEBUG is similarly slow. You can lose many, many milliseconds in DEBUG statements.

I often use conditional compilation statements (see the Stamp Manual) around my DEBUGs so I can turn them all off or on with single DEF at the top of the program.

yoda152

hears my code see attachment, the important bit of the code is from line 165 to 255 that i require to sample at a fast rate, for the purpose i require to take a sample every 0.03 seconds or less even 0.01 seconds. im basicly taking samples from an accelerometer and writing them to the data logger very fast.

thanks for your help so far

Zoot

Certainly remove the huge long debug statements that start at line 218. They're clobbering you.

That said, you still will not be able to speed up the sample rates much more past that given that you are sending fairly long strings at 9600 Baud (when writing to your log files via what I presume to be RS-232 serial to a PC host).

The only way, I think, to do something like this on a Stamp would be to save the sampled data to a local external memory then write it all to the log after the sampling period. EEPROM will wear out (eventually) and writes are slow. An I2C non-volatile (battery or capacitor backup) RAM might be a way to do it.

Or a Propeller or SX

Spiral_72

It may of may not be valid for a BS2: You'll have to research it:
It used to be: As a rule, multiplication and division take a huge amount of time to execute....... and you've got a lot of it. If you make the same calculation multiple times, you can do it once, save it to a variable and use the variable multiple times. I have done the same, and you can see a 300% increase in speed if circumstances are right. Also lookup tables work well if conditions warrant.

Spiral_72

Also, won't a BS2 run a higher speed than 9600 baud???
From the manual:

On all BS2 models, serial communication is very flexible. The Baudmode
argument for SEROUT accepts a 16-bit value that determines its
characteristics: 1-stop bit, 8-data bits/no-parity or 7-data bits/even-parity
and virtually any speed from as low as 300 baud to greater than 100K
baud (depending on the BASIC Stamp model). Table 5.106 shows how
Baudmode is calculated, while Table 5.107, Table 5.108, and Table 5.109
show common baud modes for standard serial baud rates.

yoda152

i have looked into the baud rate and 9600 is the fastest for the BS2. i have used up all the ram in my program and can not reduce it. for my project i require to take 10000 samples ( and a sample every 0.03 of a second) does this mean that eeprom is out of the question for an allternative way to store information.

do you have any more ideas?

Zoot

Well, you could use 32k external eeprom and write all your samples as you go. Without the slow serial comms, and at ~5ms per write, it would be doable. Then when the sampling is done (10000 samples), you read the data back in and write it (slowly) to your log file.

Eventually the EEPROM would wear out, but it would get you through the project.

You might be able to approach ~30ms per sample time even without that, BUT in looking over your code, you will greatly speed up your sample loop if you take all the formatting of your data out. These expressions are slow for the Stamp. Write the "raw" data to your log file, minimizing the data to write, then AFTER the fact, you can read / convert your log file on the PC side and do the formatting conversions there. Does that make sense?

Second, and here is where I don't quite follow your program -- your GET_SERIAL_BYTES is also a sample-time killer -- the timeout could take a while, and I'm not sure what the purpose of this subroutine is as the buffer is not actually used anywhere.

Spiral_72

Zoot wrote: »

Write the "raw" data to your log file, minimizing the data to write, then AFTER the fact, you can read / convert your log file on the PC side and do the formatting conversions there. Does that make sense?

That's a very good idea.

If it were me, I'd extract the inner loop: pull samples and process........ into a new program, then work on optimizing that bit. Once you feel it's as fast as possible, insert it back in to see what you have.

Spiral_72

This may be obvious to you, but it's your project.

Line 187
FOR axis = XAxis TO ZAxis ' loop through each axis
I think I know what's going on.... I think. What does this loop do? It runs through n-number of times but doesn't output anything. You are counting from 0 (xaxis) to 2 (zaxis) and pulling data off each time through. I assume your device sends the xaxis, yaxis and zaxis separately and in that order. Instead of running though all the checks each time. It would be faster and maybe smaller if you hard code it by replacing everything inside the FOR-NEXT loop with:

GOSUB Get_H48C ' read vRef & axis count
IF (axCount >= rvCount) THEN
gForceX = (axCount - rvCount) ** GfCnv ' positive g-force
ELSE
gForceX = -((rvCount - axCount) ** GfCnv) ' negative g-force
ENDIF

GOSUB Get_H48C ' read vRef & axis count
IF (axCount >= rvCount) THEN
gForceY = (axCount - rvCount) ** GfCnv ' positive g-force
ELSE
gForceY = -((rvCount - axCount) ** GfCnv) ' negative g-force
ENDIF


GOSUB Get_H48C ' read vRef & axis count
IF (axCount >= rvCount) THEN
gForceZ = (axCount - rvCount) ** GfCnv ' positive g-force
ELSE
gForceZ = -((rvCount - axCount) ** GfCnv) ' negative g-force
ENDIF

If you can do this, it'll save two nested checks each time though, times three times though or six unnecessary nested checks...... if I'm seeing it right.