ADC 0-7 inaccessible?

[pjc30943]

I'm unable to access ADC0-7.
On the surface it appears that for a 1280n device, using an ADC lower than ADC8 causes some sort of wrap-around, where only port K is used at all times.

As an example, if I read the ADC of F.0 (ADC0), it is the pin K.0 whos value is returned. Voltages applied to F.0 have no effect on the reading.

Do all the ADCs need to be enabled in any special way in native-mode devices?

[dkinzer]

Do all the ADCs need to be enabled in any special way in native-mode devices?

No, just refer to the pin numbers as usual.

Here is some test code that I used:

Code: Select all

Dim f1 as Single, f2 as Single
Sub Main()
#if 1
  Debug.Print GetADC(F.0)
  Debug.Print GetADC(K.0)
#else
  Call GetADC(F.0, f1)
  Call GetADC(K.0, f2)
  Debug.Print Fmt(f1 * 1023.0, 0)
  Debug.Print Fmt(f2 * 1023.0, 0)
#endif
End Sub

With F.0 connected to ground and K.0 connected through a resistor to +5, the output is 0 and 1023 as expected. If you change the #if 1 to #if 0 (to use the form returning a Single value) the result is 0 and 1022.

Do you get something different there? If so, what version of the ZX Library are you using? It is reported in the sign-on message or you can get it from the SerialNumber() call.

[pjc30943]

SerialNumber() result: 246, 2, 5

I define

Code: Select all

public const ADC0input	as byte = F.0

and then call

Code: Select all

getADC ADC0input, result 

Test voltages are inputted to pin1 of J6 (F.0, ADC 0) on the 1280n dev board.
When I apply voltages to pin 1 of J11 (K.0, ADC 8 ), the voltages are displayed as though I had defined ADC0input to be K.0

Or, when doing

Code: Select all

getADC ADC0input(90)

, which should be port F per the docs (pg.91 in system library), I see voltages that are applied to K.1 instead.


EDIT:

Code: Select all

getadc(F.n)

with n=0..7 and the intent of reading voltages on J6, returns the corresponding voltages placed onto K.n, J11.

[dkinzer]

SerialNumber() result: 246, 2, 5

The second two numbers look like they are part of v2.5.x. The 246 looks completely out of place. If you haven't turned off the sign-on message it should appear immediately after each reset.

There is something going on that I don't yet understand. What is the output of the test program that I proposed with F.0 grounded and K.0 tied high? Alternately, can you provide a complete program that demonstrates the incorrect voltages being read with a similar setup that I can duplicate here?

[pjc30943]

The signon has v2.5.2

I ran the program you asked, and it does indeed give the results you found.
I'm not sure why it works there, but not in the other program; I'll look into it further.

EDIT: How come debug.print does not require cstr(getADC(...)), but only getADC?

[pjc30943]

The code you had works once; if it's in a loop, it seems to no longer function. Consecutive calls yield readings from only K.0:

Code: Select all

0
1023

1023
1023

1023
1023
...

and

Code: Select all

0
1022

1022
1022

1022
1022
...

It's possible that I'm still doing something silly...

[dkinzer]

How come debug.print does not require cstr(getADC(...)), but only getADC?

Automatic value-to-string conversion for Debug.Print and the string concatenation operator (&) was added in v2.4.1. This item has been listed in the compiler change history since the release of that version. The automatic conversion is also mentioned in the description of Debug.Print.

[dkinzer]

Consecutive calls yield readings from only K.0

Right you are. The same effect can be shown by reversing the order of the two GetADC() calls in my original example.

I've tracked down the source of the problem and I know how to fix it. You can work around the problem by adding the line of code below just before each GetADC() call or, if you prefer, after each GetADC() call that uses ADC channels 9-15.

Code: Select all

  Register.ADCSRB = 0

[pjc30943]

Thanks Don. I'll use your prelim fix.