Page 1 of 1
ADC 0-7 inaccessible?
Posted: 14 July 2008, 15:31 PM
by 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?
Re: ADC 0-7 inaccessible?
Posted: 14 July 2008, 16:35 PM
by dkinzer
pjc30943 wrote: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.
Posted: 14 July 2008, 17:04 PM
by pjc30943
SerialNumber() result: 246, 2, 5
I define
Code: Select all
public const ADC0input as byte = F.0
and then call
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
, which should be port F per the docs (pg.91 in system library), I see voltages that are applied to K.1 instead.
EDIT:
with n=0..7 and the intent of reading voltages on J6, returns the corresponding voltages placed onto K.n, J11.
Posted: 14 July 2008, 17:52 PM
by dkinzer
pjc30943 wrote: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?
Posted: 15 July 2008, 11:02 AM
by 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?
Posted: 15 July 2008, 11:23 AM
by 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:
and
It's possible that I'm still doing something silly...
Posted: 15 July 2008, 14:23 PM
by dkinzer
pjc30943 wrote: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.
Posted: 15 July 2008, 14:34 PM
by dkinzer
pjc30943 wrote: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.
Posted: 15 July 2008, 14:49 PM
by pjc30943
Thanks Don. I'll use your prelim fix.