Well that's the problem. The $0800_0000 is for P27. Because of the offsets my program crashes with "mov Counter, #18" now that's rudimentary but Counter is not pointing to the right storage point and the processor will not let it store to the address assigned. This sliding thing has me perplexed.
I don't understand what you mean by "this sliding thing". Can you describe it in more detail?
As for the "mov Counter, #18", that should store the value "18" in the "Counter" register. That is the cog register at whatever address the assembler assigns to "Counter"($00C4). That instruction and the DJNZ are fine.
Well that's the problem. The $0800_0000 is for P27. Because of the offsets my program crashes with "mov Counter, #18" now that's rudimentary but Counter is not pointing to the right storage point and the processor will not let it store to the address assigned. This sliding thing has me perplexed.
Try this. Added nop's for delays and xor's to toggle as needed. Delays are a bit more than required but the conversion rate is so slow that it does not matter.
{{┌──────────────────────────────────────────┐
│ 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├─┘ 150Ω ┌─────────────┐
│ DRDY/DOUT├─────────┤ P25 │ P27 = Data ready/Data out
│ SCLK├─────────┤ P24 │ P26 = Clock for syncronizing w/
│ │ │ │ Data ready/Data out
│ PDWN├─────────┤ P26 │ P25 = Activate on 1 or 0 place A
│ │ │ │ DC in sleep mode
┌─┤ SPEED├─────────┤ P27 │ 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
'SCLK P24
'DROUT P25
'POWER P26
'SPEED P27
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 high "1", all the other pins are low
' the ADS1131 is now on
' the two insns below make sure you have a high/low transition
:loop
{optional} waitpeq DROUT, DROUT ' Wait "P25" DROUT to go/be high
waitpne DROUT, DROUT ' Wait "P25" DROUT to drive low
mov Counter, #18 '
:dataLoop xor outa, SCLK ' SCLK is now high so that DROUT
' will show data
nop ' Now I need SCLK to remain
nop ' low/high for at least 100ns
' capture and store bit(s)
test DROUT, ina wc ' sample bit (DROUT) 4 clks = 50ns
rcl Data, #1 ' store bit (use rcr for opposite order)
' 50ns + 50ns = 100ns
xor outa, SCLK ' toggle SCLK back to low
nop ' 100nS delay
nop
djnz Counter, #:dataLoop ' for all bits
xor outa, SCLK ' toggle SCLK back to high
nop ' 100nS delay
nop
xor outa, SCLK ' then toggle SCLK back to low so DROUT will go low at the next conversion
jmp #:loop ' no loop 8 clks 100ns + 150ns = 250ns
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 |<26 | |<27 ' P26 bitwise or P27 $0C00_0000
'These variables are always last
Counter res 1
Data res 1
fit
But the cog memory has variable Counter pointing to $0C000000.
Nothing is "sliding." Your Cog RAM viewer is simply wrong. The labels actually refer to the next address, not to the line on which they're shown. To prove it to yourself, just count the instructions starting from the org.
Forget the sliding issue. The PASD header is 12 longs in size. Which means your code starts at $00C, IOW the first nop is supposed to be at $012 which is in fact the case according to your listing. Two instructions before that you find the mov Counter, #18 ($A0FC4812). Which validates the #18 and Counter to be at $024. IOW, PASD gets it wrong. Period.
PASD uses a very simple parser and does not really assemble the source code. It just tries to match the code in the cog to the right source code lines. And sometimes with unusal constructs, it just fails. Looking at the code I think the line with {optional} at begin may confuse the parser (a typical Kuroneko comment ;-).
So try to remove this comment. (PASDs parser may expect that multiline comments { } do not end in the same line, but I haven't looked into the PASD source for now).
PASD uses a very simple parser and does not really assemble the source code. It just tries to match the code in the cog to the right source code lines. And sometimes with unusal constructs, it just fails. Looking at the code I think the line with {optional} at begin may confuse the parser (a typical Kuroneko comment ;-).
So try to remove this comment. (PASDs parser may expect that multiline comments { } do not end in the same line, but I haven't looked into the PASD source for now).
Andy
Removing the quote {optional} corrected my problem...all is good now
I wish to that everyone for their help. I learned a lot and rebuilt lost confidence...sometime that is all we need. It's good to see something work.
Comments
I don't understand what you mean by "this sliding thing". Can you describe it in more detail?
As for the "mov Counter, #18", that should store the value "18" in the "Counter" register. That is the cog register at whatever address the assembler assigns to "Counter"($00C4). That instruction and the DJNZ are fine.
But the cog memory has variable Counter pointing to $0C000000. I can't figure why the memory is sliding...except for an error in the PASM debugger.
-Phil
PS - made some changes in post 30.
So try to remove this comment. (PASDs parser may expect that multiline comments { } do not end in the same line, but I haven't looked into the PASD source for now).
Andy
Removing the quote {optional} corrected my problem...all is good now
I wish to that everyone for their help. I learned a lot and rebuilt lost confidence...sometime that is all we need. It's good to see something work.
THANK YOU ALL
-Phil