little assembly problem.

R Baggett

I don't have much experience with Propeller assembly beyond some modifications of existing code.

In the attached file, I am waiting for the arrival of three pulses using three different cogs, I record the cnt value for each, and the main object then decides which was first, and then calculates the difference in arrival time for the others, finally displaying the results on an LCD. It works well, but I find some granularity in the measurements, presumably due to SPIN's need for hub access.

So, I wrote an assembly version of the SPIN object for the three capture cogs. It's short, it's sweet, it's simple, it doesn't work.

What I'm doing wrong is probably totally stupid and obvious, but I'm stumped... HELLLLLP!!

[noparse][[/noparse]code]

Cluso99

The nop is not necessary. It is only reqd if you are modifying the following instruction as the instruction is fetched before the write has taken place.

You need a "#" in the jmp address...

jmp #loop

The "#" means the address, whereas without the "#" means get the address to jump to at the label (i.e. indirect)
However, you should get 1 valid set of values but...

The GetDisp routine is overwriting your values with
· M1 := C1....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

MagIO2

Can't give you a solution in a quick response, but here are some thoughts without even looking in your code:

If you do it in SPIN in a selfmade loop where you have something like IF INA[noparse][[/noparse] port ]==1 ... then I'd say that this is a version as inaccurate as it could be. Depending on where the signal changes it can take different times until the cnt is copied to a variable.

If you use waitpeq the COG is stopped to wait for the signal change. It continues with the accuracy of the clock-cycle-time, which is 12,5ns. All things going on from there will not add to much to the error in case the next instruction is the copy of the cnt value. But it will add some variable clocks for HUB access and for runtime - where the runtime part can be corrected due to the fact that code execution is fully deterministic.

The best result you can get in SPIN by using a counter. There is a mode where the counter runs in case a input pin has a certain state and stops in the other case. You can setup the counter to increase as fast as the cnt. So, you wait as before but then you read the value from the stopped counter. You only need to be sure that the runtime is lower than the time the signal stays in stop-level. In the propeller document area there is a lab which shows you some examples of counter programming.

In PASM it's easy
waitpeq pin_state, pin_mask
mov t_measure, cnt
wrlong t_measure, hub_ram_address

You can even subtract the cycles needed to execute the rest of waitpeq and the part until mov has really loaded the cnt value. But as all COGs have the same error it's irrelevant.

R Baggett

Cluso: Thanks! That was exactly what it needed. You even caught my mix-up in arranging the variables in the AssyRead routine! (I mixed up the M1 vs C1 when I started the cogs!) I KNEW it was something like that, I just couldn't see it. Thanks again! (I also removed the nop.)

Magi02:

Thanks for taking the time to offer an answer. I believe that my 'granularity' problem was due to the fact that SPIN will need hub access to fetch the next instruction after a waitpeq. I never examined it mathematically, but my numbers were all coming out even, I NEVER got an odd result. This makes sense, as hub access comes every 16 clocks and 16/8 cogs is even. Then there is the unknown wait for that hub access. The now working Assembly version gives even/odd answers in the correct distribution with a known delay, which cancels due to it's presence in all three signals. Thanks again!