Trying to understand the PASM waitpeq command
jaschandler
Posts: 23
I just want to know if I'm using the waitpeq command correctly.
{{┌──────────────────────────────────────────┐ │ ADS1131 18-Bit ADC for Bridge Sensors │ │ Author: James L Chandler │ │ │ └──────────────────────────────────────────┘ The DATA READY/DATA (DRDY/DOUT) output pin serves two purposes: 1. It indicates when NEW Data is ready to be read by dropping from its normally high state to low. 2. Afterwards on the first rising edge of SCLK, the DRDY/DOUT pin changes its func- tion and it then starts outputting the ADC converted data w/ the (MSB) most significant bit first i.e. bit 17, bit 16, bit 15,...bit 2, bit 1,and the last bit 0. Data are shifted out on each subsequent SCLK rising edge. After all 18 bits have been passed, the DRDY/DOUT pin is then forced high on the next SCLK rising edge where it remains high until the next data cycle is about to start. This program waits while monitoring the DRDY/DOUT pin. As soon as this pin drives negative this alogrithim activates. It then looks for the first rising edge off the SCLK pin. The algorithm then measures DRDY/DOUT for a high or a low state. A 1 (logic high) or 0 (logic low) is then pushed onto the stack. Once the 18th data bit has been read and placed on the stack the algorithm pulls data off the stack in (LSB) least significant bit first. The data is then returned in 5 digit Hex format "The positive full-scale input produces an output code of 1FFFFh and the negative full- scale input produces an output code of 20000h." IN BINARY TWO COMPLEMENT format. 5.0V ADS1131 3.3V  ┌─────────────┐  P8X32A └──┤AVDD DVDD├─┘ 1KΩ ┌─────────────┐ │ DRDY/DOUT├─────────┤ P27 │ P27 = Data ready/Data out │ SCLK├─────────┤ P26 │ P26 = Clock for syncronizing w/ │ │ │ │ Data ready/Data out │ PDWN├─────────┤ P25 │ P25 = Activate on 1 or 0 place A DC in sleep mode │ │ ┌─┤ SPEED├─────────┤ P24 │ P24 = Speed select for the ADC:  └─────────────┘ └─────────────┘ 1. A logic zero 0 sets the chip to 10 samples per second (SPS) or 2. A logic one (high) sets the chip to 80SPS }} CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 VAR long Cog, TestVar OBJ dbg : "PASDebug" '<---- Add for Debugger PUB main Cog := cognew(@entry, @TestVar) + 1 dbg.start(31,30,@entry) '<---- Add for Debugger PUB stop if Cog cogstop(Cog~ - 1) DAT org 0 entry ' --------- Debugger Kernel add this at Entry (Addr 0) --------- long $34FC1202,$6CE81201,$83C120B,$8BC0E0A,$E87C0E03,$8BC0E0A long $EC7C0E05,$A0BC1207,$5C7C0003,$5C7C0003,$7FFC,$7FF8 ' -------------------------------------------------------------- ' ' Test code with modify, MainRAM access, jumps, subroutine and waitcnt. ' StartupADS1131 mov dira,START ' P26 & P27 output low mov outa,POWER ' P26 is shifted high "1" the ADS1131 is now on waitpeq $1, DROUT ' Wait "P25" DROUT to go high waitpeq $0, DROUT ' Wait "P25" DROUT to go high mov Counter, #5 ' :loop waitpeq $1, SCLK ' Wait "P25" DROUT to go low nop djnz Counter, #:loop wz ' Loop 5x because the measurement is not yet reliable mov Counter, #19 ' Set Counter for next loop ReadData :loop waitpeq SCLK,SCLK ' Wait for SCLK to go positive nop ' ' VARIABLES ' SCLK long |<24 ' Pin P24 $0100_0000 DROUT long |<25 ' Pin P25 $0200_0000 POWER long |<26 ' Pin P26 $0400_0000 SPEED long |<27 ' Pin P27 $0800_0000 START long $0C00_0000 ZERO long $0000_0000 HIGH long $FFFF_FFFF ' res variables are always last Counter res 1 fit 496
Comments
SCLK: Digital input Serial clock: clock out data on the rising edge.
P.S WAITPEQ does not wait for an edge so if the state is still correct from the last one you have to wait for WAITPNE first
-Phil
I also changed
The "waitpeq one, DROUT" locks up the processor. I find this odd because it's shows high and 90% of the time it should be.
I also took Tony's advise and changed the rest of my waitpeg commands to waitpne i can see where this may be a better choice.
However if I comment out the "waitpeq one, DROUT"
the program will pass through "waitpne one, DROUT" without any problems
but it then locks up at "waitpne zero,SCLK" so I changed it to "waitpne one,SCLK" and that works.
The ADS1131 has it's own clock and requires the end user to read the data using its clock. Doing so I was glad to see pass through...however this would have me sync to the negative going direction of SCLK and I need to be on the positive going side,
The code now goes through but I need to look for the first positive SCLK pulse and compare that with DROUT to know what state that data pulse is in.
I thought the waitpeq stopped the cog until in my case DROUT is positive. It's positive 90% of the time so why is it waiting forever? What am I missing in how waitpne works?
And why does the COG pass through SCLK as it goes negative but not when it goes positive. I never found anywhere where someone was able to read an ADS1131 ADC chip. I really want the propeller chip to be the one that reads the data. There are so many things I can do with a working scale. And I seem to be hammered down with something that should be easy. So without further rambling here is the code right now:
-Phil
I haven't been able to make the literal symbol ( # ) work reliably with the WAITPEQ and WAITPNE statements. Have a look at WAITPEQ in the manual for example. WAITPEQ State, Mask will wait until INA ANDed with Mask matches State. The program will then continue with the next instruction.
These two constructs work for everything that I've been doing so far.
I imagine the literal operator might work for pins 0 through 8 since a literal value is only 9 bits but I haven't tried it.
Sandy
Kuroneko I see my errors and have a better understanding of waitpeq & waitpne. I changed my code as follows; however a new problem has cropped up. It will now wait at "waitpne SCLK, SCLK".
I found this to be rather odd so I looked at the cog memory and found:
Addr Value Label
012 $F03C2E17 -264491497
013 $613C31F2 1631334898
014 $34FC3A01 888945153
015 $E4FC3811 -453232623
016 $F07C2C00 -260297728 SCLK <==I did not expect to see this happening
017 $01000000 16777216 DROUT This is the pin for SCLK
018 $02000000 33554432 POWER It continues but they are all off one
By looking at this I can see why I get past DROUT because it is actually looking at the SCLK pin. The SCLK command stops because of what it is looking for.
All my variables have slipped one throwing everything off. How is this happening and how do I prevent it?
As a quick test, you could use an edge counter monitoring that pin (ctra := %0_01010_000 << 23 | 24) load frqa with a non-zero value and check the value of phsa after you applied power to the converter. Just to confirm that there is a clock.
From the datasheet it looks like SCLK is a digital input. So who - if not the propeller - is generating said clock?
Also, your pin assignments don't seem to match the diagram:
From what I see on the PPDB board drawings that I'll need to write code to toggle P25 so that this will work...but this will waste another cog.
Do I need another outside chip? I'm thinking out loud...this is all new to me.
1 - Toggle SCLK (pin 24 from low to high to low) to place the MSB bit data out to DRDY/DOUT
2 - Read DRDY/DOUT in to a variable and shift left one bit
3 - Repeat for the other 17 bits (or as many as you want)
PS - You should toggle the SCLK 19 times per read even if you don't need all the bits in order to set DRDY/DOUT back to high so you can wait for it to go low at the next conversion.
I hate bothering people but in the end I'm learning and moving forward lol
SCLK is still slewed wrong...
I'm not seeing where the z flag is being set prior to the first muxz call. If you just want to toggle the state of the SCLK pin you could use xor outa, SCLK instead.
Sandy
START long |<26 | |<27 resuls in $08000000 not $0C000000
I think it needs to be:
START long %11 <26
-Phil
Alexander thanks I'll look at that and correct it I was looking at shifting the SCLK (something I've never done).
But for the life om me I can't figure out why the code in the variables lined up and now they are off. SCLK is no longer pointing to $01000000 but after loading it into the chip it SCLK is pointing to $F07C2C00 even though the code looks right something in the variable defining has happened and I can't see it.
Here it is lined up
Suddenly it wrong
I didn't understand it either at first but | is bit wise or so 4 hex (0100) bit wise or with 8 hex (1000) and ends up with C hex (1100). I tried re-using $0C00_000 and my variables are still shifted. I liked the bit wise or idea it fall in line with everything else.
In the .gif from post 18 the value is $08000000. Should it not be $0C000000 ?
-Phil
May need a delay nop as well.