Polling an input in ASM

Jonathan

Hi All,

I'm getting back to work on a project, an ultrasonic relative positioning system for the classroom. There are three US beacons, each with an RF RX. The robot requests a ping from each beacon in turn, and do a little math and we know where we are.

Using SPIN, the shortest distance I can measure seems to 17cm. I haven't set it up on a 'scope to check, but I am assuming that this is the speed limitation of SPIN.

So, I am trying to wrap my head around some ASM. What I need is more than "ASM for Dummies." I need "ASM for Total Morons." :-)

I understand that I need to init a cog to run the ASM. Here is what I am trying to do, in SPIN instead of ASM

pri nav_cog
  navCogID := cogid ' Just in case we want to know which cog
  dira[noparse][[/noparse]navIn] := 0 ' Make pin an input
repeat
  repeat until ina[noparse][[/noparse]navIn] == 1   ' Wait for pulse
    pingStop :=  cnt   ' record cnt   
    pingFlag := 1      ' Set pingFlag to received

None of my ASM attempts are worth putting here. Anyone know of a source of *extremely* simple ASM info?

Thanks!

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot

Mike Green

Actually, you shouldn't need to use assembly. You can use the cog counters for pulse timing. That will give you a resolution to about 25ns. There's an application note (AN001) on the counters in the Propeller Download area (www.parallax.com/propeller/downloads.asp).

Graham Stabler

Please see Mike's post for the solution to your problem but may I recommend my 4 step plan for learning some asm basics:

http://forums.parallax.com/showthread.php?p=647408

All the programs need no more than a few leds, it works on the demoboard vga leds if you have one of those.

Graham

Jonathan

Mike,

Let's get it out there that I am a thicky. That said, I downloaded the counters application note, and I don't get how this will help. I thought that the limitation I was running up against is how quickly SPIN can perform the IF statement and poll the input.

Graham,

Thanks for the ASM link. I'm going to play with the examples you gave today and see if I can manage to figure it out. I'm not holding my breath tho... :-0

Thanks for the help, gentlemen!

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot

Jonathan

I just had a thought that my aims might not be clear. The Prop 'bot sends a request for and ultrasonic ping from one of the beacons. The prop makes a note of CNT when it makes the request, then polls an input which is connected to a comparator. When the comp goes high beacuse the receiver has gotten the return signal, we again note where CNT is, subtract the start time from the finish time, subtract a little more for the overhead involved in the RF link and the time it takes the beacon to transmit the pulse.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot

Mike Green

Jonathan,
The two cog counters run off the system clock (usually 12.5ns/cycle) and can be gated in various ways. You can set one to run when an input pin is high or when an input pin is low and it will accumulate the number of clock cycles. After the pulse is done (you wait in a loop in Spin), you can read the count from Spin and reset the counter (none of this requires assembly language). The pulse timing is accurate to a 12.5ns granularity and is independent of delays in Spin.

Jonathan

Mike,

Aha. I get it, and now I'll see if I can do it. Thanks a bunch, 12.5nS resolution is way more than I need. Although Im still going to play with Graham's ASM stuff, upon reading it *some* of it was actually making sense to me.

Thanks again, off to play with counters!

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot

Tracy Allen

Hi Jonathan,

Just to extend Mikes comment, Spin would set up a counter for NEGDET mode with the frqa initially 0. Then Spin sends the the request for a ping and immediately thereafter sets the frqa:=1, and from that time until the comparator goes high, the counter accumulates the time. How is the robot requesting the ping? If it involves setting a Prop pin, then the timing could be done with even greater precision by using one of the logic modes of the counter. The apin input would be the comparator, and the bpin input would be the pin that is requesting the ping. The counter advances only during the time between the edges.

In your original Spin program, there is a repeat loop for the polling. Why not use a waitpxx?
waitpeq[noparse][[/noparse]|< navIn, |< navin, 0] ' hold here until comparator high
pingStop := cnt ' record cnt

That would eliminate uncertainties in the waiting for response. The ping request would have to be tightly linked into that and coordinated with whatever processing delays exist in the beacons. I'm unclear on what you mean by "the shortest distance I can measure seems to 17cm". Is that the uncertainty at any distance, or the minimum distance from bot to beacon? By my quick calculation, sound travels that 17 cm in roughly 0.5 millisecond, which it seems is not out of bounds for Spin with 80mhz clkfreq.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Jonathan

Tracy,

Going to get to tryng your and Mike's suggestions shortly. I saw your post and thought I'd answer your questions.

The robot requests a ping from the beacons using a RF link. The 'bot has a TX module, and the beacons have an RX module. The beacons use an SX chip, which waits for the request, then sends 10 pulses at 40kHz.

The 17cm limitation is the minimum distance from the 'bot to the beacon. The system is pretty accuarate above 17cm and the delay between the request and the beacon sending it seems pretty consistant. After I get this new counter thing working, I'm going to set up a 'scope to measure the actual delay between the request and sending the signal, although my calculations seem to be working pretty well, I might as well verify it.

Thanks for the help!

Jonathan



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot

rokicki

Okay, can you let us know *how* the robot requests a ping using the RF link? Are you using the prop's built-in PLLs to
generate the RF, or are you using a separate transmitter somehow? If you're using a separate transmitter, how are
you talking to it [noparse][[/noparse]serial connection, modulator input from a propeller pin, etc.?]

In any case it sounds like you're having fun.

Jonathan

Rokici,

I am using the Parallax 433mHz modules. The 'bot has a TX and the beacons have an RX. Each beacon waits for it's unique identifier, then sends a train of 10 40kHz pulses. The·request is sent using Martin's BS2.functions in serial format.

And yeah, I am having fun! The system shows great promise, and I will be able to plot the bots position to within a few cms in the classroom and display it on a laptop. The PC software is under development with the help of a friend and is working well too. Ultimately, you will be able to click on the map and the 'bot will automatically travel to the location selected. As soon as I get the nav system hammered out, I will be adding object mapping to the PC software.

Tracy,
I tried the WAITPXX command as you suggested. It does indeed work, but I get the same 17cm limitation. I'm not sure why, and today is being one of those days where things keep coming up and distracting me. Here iare the code snips I am using, the first is my original code:

pub ping_one
    dira[noparse][[/noparse]navIn] := 0 ' Make pin an input 
    cm := 0
    pingFlag := 0   ' Reset pingFlag  
    pingStart := cnt  ' Record start time
    BS2.Serout_str(rfOut,string("A"),rfBaud,rfPar,rfBits)  ' Send ping request
    repeat 1200     ' If we dont get a ping in 1200 iterations, try again
      if ina[noparse][[/noparse]navin] == 1   ' Wait for signal
        pingStop :=  cnt    ' Record receive time
        rawRange := (pingStop - pingStart) ' Calculate raw range
        cm := ((rawRange - overhead)/ factor) ' Subtract overhead and convert to CMs
        quit
return

And this is the one with your waitpxx suggestion:

pub ping_one
    dira[noparse][[/noparse]navIn] := 0 ' Make pin an input 
    cm := 0
    pingFlag := 0   ' Reset pingFlag  
    pingStart := cnt  ' Record start time
    BS2.Serout_str(rfOut,string("A"),rfBaud,rfPar,rfBits)  ' Send ping request
    waitpeq(|< navIn, |< navin, 0)
    pingStop :=  cnt    ' Record receive time
    rawRange := (pingStop - pingStart) ' Calculate raw range
    cm := ((rawRange - overhead)/ factor) ' Subtract overhead and convert to CMs
return

Both snips behave the same way, I have the 17cm problem with both. Also, in using the waitpxx command, I am going to have to figger out a way to have it timeout in case I do not get a return signal.

Thanks to all!

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot

Tracy Allen

How do you determine the "overhead"? Empirically? That would have to encompass the time required for the BS2.serout to interpret and execute , plus the time for the SX to initiate the 40khz wavefront, and the response time of the comparator once it first sees the wavefront. Yes, a 'scope would probably show something interesting, not sure what.

So, the distance measured is accurate at, say 20cm and at 100cm. But what actually happens as the bot crosses inside that 17cm limit line?

One way to implement a timeout would be to use a second pin on the Prop. Attach an RC circuit from that pin to Vdd, with a time constant of say 1 second. Then use waitpne instead of waitpeq:

dira[noparse][[/noparse]RCpin] := 1
outa[noparse][[/noparse]RCpin] := 0  ' drag the wait pin low
dira[noparse][[/noparse]RCpin] :=0   ' let it RCtime
waitpne(0, (|< navin) | |< RCpin), 0)  ' either navin or RCpin whichever high first
if ina[noparse][[/noparse]RCpin] = 1
  timeoutflag :=1
pingStop :=  cnt    ' Record receive time

The timeout could also be intiated by a counter module or another cog, affecting an auxiliary pin.

Yeah, it sounds like great fun. I do a lot of work with people researching bats, and we use remote microphones. A lot of people are interested in tracking the animals as they fly by. Of course, we can't have the bats (easily anyway) send out RF requests, but one of the possibilities that came to mind with the prop was a three cog three channel correlator.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Jonathan

Tracy,

I *think* I did hook up a 'scope to get an idea of the latency, but this was back when the Prop was still in beta, so I can't be dead sure what I did. I think I got an idea of it with the scope and then tweaked it empirically.

When I cross the 17cm line, the rawcount is always the same, and hence the cm result is always the same. I have to run an errand, but when I get back I'll hook up a 'scope and see if I can come up with anything intersting.

I see what you are saying about using a second pin for a timeout. I'd rather not go that way as I am already low on pins. All I really need is to reduce the the minimum distance to a few CMs, which it seems like I should be able to do with SPIN. Since the beacons are going to be in ~ a 20'X20'X20' equilateral triangle, I don't have to worry all that much about being too close to a beacon, but I'd like to get it as tight as I can.

Thanks so much for the help!

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot

Jonathan

Tracy, All,

Setup to test things with the 'scope yesterday. It seems that the reason I am having problems is the length of time it takes the program to return from the BS2FUNCTIONS serout command requesting the ping from the beacons.

I set up the scope so that the trigger takes place right after I send the request for the ping. Channel one monitors the trigger, which is sent high to start the scope and then goes low after ping has been recieved. Channel 2 is monitoring the beacon, where I am have a pin go high just before the 40kHz pulse train is sent, then goes low immedialty after the pulse train.

With this setup, I see a delay of ~ 652uS until the Prop arrives at the receive loop. After that, I get 25uS resolution as expected. There are a few more factors involved, such as the fact that the comparator usually triggers on the 3rd pulse of the train, adding andother 37uS, etc. However, it appears that the main issue is how long it takes the SEROUT routine to drop into the recieve loop.

WAITPXX is *slightly* faster than a polling loop. However, it does not affect the minimum distance because the polling loop is not the issue.

So, I guess I'll mess with some of the other serial comm objects. I found full duplex serial, but can't find the simple_serial I see folks talking about.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot

Tracy Allen

Hi Jonathan,

SimpleSerial is found with the distribution of the IDE, I think. Since you are only using the tx part, it might be easier just to rip that out of the library. Here is the tx part as a standalone and trimmed of a few extras.

PUB tx(txByte) | t
'' Transmit a byte
    bitTime := clkfreq / baud                         ' calculate serial bit time  
    inverted := -1                                ' inverted mode, start bit=1, idle state=0
    outa[noparse][[/noparse]sout] := !inverted                             ' set idle state
    dira[noparse][[/noparse]sout]~~                                        ' make tx pin an output        
    txByte := ((txByte | $100) << 2) ^ inverted         ' add stop bit, set mode 
    t := cnt                                            ' sync
    repeat 10                                           ' start + eight data bits + stop
      waitcnt(t += bitTime)                             ' wait bit time
      outa[noparse][[/noparse]sout] := (txByte >>= 1) & 1                  ' output bit (true mode)
    ' trigger for 'scope goes here

It doesn't matter about a little fat at the start, but after the data is transmitted it needs to return to waiting ASAP. There is the stop bit. Is the request for Ping a single byte? I don't recall if you stated the baud rate. But the beacon may or may not wait around for the complete stop bit at the end of the request. It doesn't matter, modify the routine to repeat 9 instead of repeat 10, and add outa[noparse][[/noparse]sout] := inverted to initiate the stop after the final byte of the request for Ping.

The code for the transmit could go directly in line before the code for the waitpne[noparse]/noparse. That would eliminate all the overhead for calling the PUB. I don't know how much overhead that is, timewise.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Jonathan

Hehe! Got it working using the full_duplex object. It was indeed the return time of the BS2.Functions object. Observed and calculated measurements now add up. The Prop now drops into the polling loop WAY before the pulse train is sent from the beacon. It appears that I now have a resolution of ~ 1cm, I'm still testing. Have to redo the math of course, but that should be no big deal.

Thanks for all the help folks! I have to say that the Parallax USB scope is a good little piece of equipment for the price. Would have been a tough one to figger out without one.

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot

Jonathan

Haha! I'd been looking at this on the 'scope only. When I went to debug the data, I got nothing. Puzzled, I looked around until I saw that the Prop was dropping into the polling loop so fast that the comp was already triggered, giving a result of almost 0 everytime. Took me a while to figger out that the RF from the TX module is causing the comp to trigger when the RF data is sent! Looks like I'll need to shield the op amp on the ultrasonic side of things from RF. For a workaround, I just added a delay before I drop into the polling loop.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot