Pico - analogRead()

Hi All,

Just a quick one with regards to analogRead() values I'm getting back from pin A5 on the Pico:

	const solarIn = analogRead(A5);
	const dataRead = () => {return (solarIn * 3.3) / 65536;};

• console.log output being this:
  0.00005031789 or 2.45872911421e-8
  
  

-using the terminal for querying gives me an output between 0 & 1:

>analogRead(A5);
=0.99879453727
>analogRead(A5);
=0.41113908598
>analogRead(A5);
=0.00073243305

any ideas? I'm sure I'm doing something wrong but can't figure out where...

Regards,
George M.

Got it... seems a quick math on the pure analogRead() checks out:
((65536 * 0.99879453727) * 3.3) / 65536 = 3.296021972991

Whew! . . . @GeorgeM glad my telapathic thoughts helped!!

@GeorgeM Arduino gives integer values that depend on the range of the ADC. Sometimes it's 0..1023, sometimes 0..4095. For Espruino I figrued it was more sensible if analogRead always gave values in the range 0..1 - but that does mean if you had code written for Arduino (which seems to be expecting a range of 0..65535?) then the scaling will be wrong

Haha, it sure did! ...it took me a minute to see it.

Yep, was familiar with the way Arduinos work... MicroPython/ CircuitPython are doing the same, using the ADC value, so that's why I was a bit in the woods with this one... but do get your point when scaling's involved.

If you want to have logic working in all places, you write an environment dependent wrapper and use that wrapper. Normalizing to a decent range (resolution - number of significant digits - desired 'accuracy') is always a good approach. And, if you have the issue to only be able to deal with integers 1 up to 4 bytes - pos only or neg and positive - convert (scale and offset) to desired range (always knowing how to properly interpret the 'new' value).

Yep, a wrapper is a great idea, especially in the asynchronous way JS works; I'm just about 6weeks into JavaScript and 4-5days into Espruino... and let's say it's quite different when compared to C++, Python.

@GeorgeM, indeed, Espruino devices and JS language environment make a quite different IoT world. Coming from Python, JS looks a bit crisper... even though some Python concepts and constructs aren't available. I moved the other direction and liked Python as well... not as much as JS, and for sure not as much as Smalltalk (-80, /V, IBM/VA/st (then), Squeak). Python on a powerful system is of course not comparable with an Espruino JS environment, because the targeted application space is different: Espruino goes (primarily) for resource frugalness w/o sacrificing modern concepts, such as oo and events, enabling high but also allowing low level things with an extremely low entry threshold and a great learning curve. Switching to a context similar but different makes it even more different, and you will experience head scratching, inner yelling - How dare... - resolved with the liberating and empowering Ahas. Every thing has its beauty! ...only to spend more time on one than others.