Regarding ADC Sampling rate

[NAVNEET ACHARYA]

Sir,

What's the ADC sampling Rate ? Can I measure 10^5(100,000)

readings per second or one sample in 10 MicroSec ?

Please reply as fast as possible.

Regards,

Navneet Acharya

[RMDumse]

The fastest possible reading on the A/D can be done in 1.6uS. The first conversion will take a little longer, then the repeated readings after that can come that fast. You might have to resort to assembly language programming to move the data around at that rate.

See the downloads page for the DSP56F801-7UM.PDF from the Motorola site which has extensive detail on the A/D in chapter 9.

[NAVNEET ACHARYA]

Sir,
I am not getting 1.66*10^6 samples per second.

I am getting only 587 samples.

I am sending my program along this mail.

Please see My program and give suggestions.


300 CONSTANT 1-SECOND
: WAIT-1-SECOND ( -- ) TCFTICKS @
BEGIN
TCFTICKS @ OVER -
1-SECOND > UNTIL
DROP
;
FVARIABLE TEMP
FVARIABLE TEMP1
VARIABLE TEMP2
0 TEMP2 !
3.30e FCONSTANT VREF
VREF TEMP F!
: GET-AD
CR
13 EMIT
ADC3 ANALOGIN S>F VREF FSWAP 32760.0e F/ F* TEMP1 F!
;
MACHINE TEST
ON-MACHINE TEST
APPEND-STATE X1
IN-STATE X1
CONDITION
GRNLED ON ?
CAUSES
GET-AD
TEMP2 @ 1 + TEMP2 !
THEN-STATE
X1
TO-HAPPEN
IN-STATE X1
CONDITION
REDLED ON ?
CAUSES
WAIT-1-SECOND
GRNLED OFF
THEN-STATE
X1
TO-HAPPEN
IN-STATE
X1
CONDITION
GRNLED OFF
CAUSES
TEMP2 .
0 TEMP2 !
TEMP2 @ .
THEN-STATE
X1
TO-HAPPEN
X1 SET-STATE
INSTALL TEST

Thanks,

Regards,

Navneet Acharya

[RMDumse]

The 1.6uS rate is a hardware conversion rate. What can be done in software is entirely another matter.

I am getting only 587 samples.

Well, I would be surprized if you are actually getting that many samples. I see problems in your program.

You have a BEGIN AGAIN in a statemachine which are PCC's and prohibited if you want your program to run fast in IsoStructure.

Then I notice you are doing printing (serial output) in your program. Serial channels have time constraints, so it may not be possible to run fast and do serial as well. For instance, at 9600 baud, you can do about 1000 characters a second. If you did one character with every conversion, you could only do 1000 conversions a second. I notice you do a CR and a 13 EMIT with each GET-AD, so you can probably do only ~500 conversions a second just because you are waiting on the serial channel to clear characters.

Now, let's look at your transitions. The CONDITION CAUSES phrase should return a boolean on a stack between CONDITION and CAUSES. None of your transitions do that. So there are stack imbalance problems.

The first transition says

CONDITION
GRNLED ON ?
CAUSES

which turns the GRNLED ON and then ? prints the top number on the stack. That means after the causes, the stack has been stripped of a value and is missing another value. I suspect what you want is

CONDITION
GRNLED ON?
CAUSES

which checks to see if the GRNLED is on and leaves a boolean truth value.

The space between ON ? makes two words with different meaning than ON?.

The second transition says

CONDITION
REDLED ON ?
CAUSES

which has the same problem, and you probably mean

CONDITION
REDLED ON?
CAUSES

without a space between ON and ?.

The third transition says

CONDITION
GRNLED OFF
CAUSES

There is no ?, there is no boolean, there is a stack imbalance problem from CAUSES taking its boolean (that hasn't been put there for it).



So, I am confused by the program, because I can't figure out exactly you are trying to do. Perhaps you could describe what you are trying to do, or what you want to have happen, so I could help more.


I can see places where I can help improve the program. For instance in the first transition, you increment TEMP2 each time through the action phrase. This can be done simpler, because there is an increment word in the language which is much faster. Where you have

TEMP2 @ 1 + TEMP2 !

you could use

TEMP2 1+!

which is simpler, takes less memory, and runs much faster. But this is only a matter of choice for the programmer, as both ways have the same end effect.

[NAVNEET ACHARYA]

Sir ,
Actually in earlier program i want to measure how many samples
can be read within 1second.

That's why i am using 3 tarnsitions based on conditon of red and green led as these are GPIO(PD0-PD3 PINS).

In first Transition I am simply getting reading from ADC pin
and Incrementing a variable named TEMP3.

In second transition I introduce 1 second delay thereafter i am
turning off greenled .

In Third Transition I am just displaying Value of Variable.

This is my program:


100 CONSTANT 1-SECOND
: WAIT-1-SECOND ( -- ) TCFTICKS @
BEGIN
TCFTICKS @ OVER -
1-SECOND > UNTIL
DROP
;
FVARIABLE TEMP
FVARIABLE TEMP1
VARIABLE TEMP2
0 TEMP2 !
3.30e FCONSTANT VREF
VREF TEMP F!
: GET-AD
CR
13 EMIT
ADC3 ANALOGIN S>F VREF FSWAP 32760.0e F/ F* TEMP1 F!
;
MACHINE TEST
ON-MACHINE TEST
APPEND-STATE X1
IN-STATE X1
CONDITION
GRNLED ON?
CAUSES
YELLED OFF
GET-AD
TEMP2 1+!
THEN-STATE
X1
TO-HAPPEN
IN-STATE X1
CONDITION
REDLED ON?
CAUSES
WAIT-1-SECOND
GRNLED OFF
THEN-STATE
X1
TO-HAPPEN
IN-STATE
X1
CONDITION
GRNLED OFF?
CAUSES
TEMP2 .
0 TEMP2 !
TEMP2 @ .
THEN-STATE
X1
TO-HAPPEN
X1 SET-STATE
INSTALL TEST


Please Give me suggestions.

Waitting for response.

Thanks.
Regards,

Navneet Acharya

[RMDumse]

This design is not optimal. You have a PCC loop still in the "WAIT-1-SECOND" word. Nothing else operates while this is running. PCC loops don't belong in state machines, particularly in transition actions. So I don't think it is possible to use this program to get what you want.

How about if we take a different approach. It is fine to use PCCs in the foreground when you're testing things. So if you want to see how fast you can do A/D conversion, why not just run a loop in the foreground and see how long it takes?

First, let's make GET-AD run fast as possible.

Get rid of the CR and 13 EMIT which generate serial characters (returns) which do us no good, and only slow down the word.

Next, let's not scale the A/D reading into a float, but just store it as a integer.

: GET-AD ADC3 ANALOGIN TEMP1 ! ;

Now, that is the fastest you can take an A/D reading using the OO words provided in the language.

So, we need a way to run this as fast as we can for a second. We will use a foreground PCC loop

: TEST
0 TEMP2 !
TCFTICKS @
BEGIN
GET-AD
TEMP2 1+!
TCFTICKS @ OVER - 1-SECOND >
UNTIL
DROP
TEMP2 @ .
;

So, this isn't absolutely as fast as it could run, because it takes time to do the TEMP2 1+! and TCFTICKS... stuff. But it will give you an idea at least.

So here's the source I came up with to test this:

100 CONSTANT 1-SECOND

VARIABLE TEMP1
VARIABLE TEMP2

: GET-AD ADC3 ANALOGIN TEMP1 ! ;

: TEST
0 TEMP2 !
TCFTICKS @
BEGIN
GET-AD
TEMP2 1+!
TCFTICKS @ OVER - 1-SECOND >
UNTIL
DROP
TEMP2 @ .
;

ISOMAX-START

and here's the result I got:


ISOMAX-START OK
TEST 4931 OK

So using the OO words and a loop, with some loss to the TCF running in the background, it ran a little less than 5000 in a second.

So, you won't get 100,000 a second with the OO high level words. This isn't surprizing, as they were made to be convenient, rather than fast.

We could get much faster by setting up the A/D at the register level. Let me save that for another post.

[RMDumse]

By going straight to the hardware and telling it to convert as fast as it can, we can tell the A/D to give us new readings on all 8 channels, one per ~2uS period, which is faster than we can get to the results in the language. So we'll do that. Then we'll see how fast we can take the readings and put them in TEMP1

DECIMAL
100 CONSTANT 1-SECOND

VARIABLE TEMP1
VARIABLE TEMP2

HEX
: INIT
2003 0E80 ! ( ASSIGN ADC CONTROL REG 1
003D 0E81 ! ( ASSIGN ADC CONTROL REG 2
3210 0E83 ! ( ASSIGN ADC CHANNEL LIST REG 1
7654 0E84 ! ( ASSIGN ADC CHANNEL LIST REG 2
;

: GET-AD E8C @ TEMP1 ! ;
DECIMAL

: TEST
0 TEMP2 !
TCFTICKS @
BEGIN
GET-AD
TEMP2 1+!
TCFTICKS @ OVER - 1-SECOND >
UNTIL
DROP
TEMP2 @ .
;

INIT
ISOMAX-START

And the result I get is quite a bit faster than using the OO words.

ISOMAX-START OK
TEST 31857 OK

So we have over 30,000 readings actually taken and put in a variable. But there's still the additional overhead of the other words in the loop. So if we were doing nothing but fetching and storing, we'd probably be at the 100,000 rate.

But this is outside the limits of a high level interactive language. You will probably have to go to assembly language to get much use out of taking data this fast.