Pico - analogRead()

[espruino-discuss]

Posted at 2021-05-19 by GeorgeM

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.

[espruino-discuss]

Posted at 2021-05-19 by GeorgeM

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

---

Posted at 2021-05-20 by Robin

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

---

Posted at 2021-05-20 by @gfwilliams

@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

---

Posted at 2021-05-20 by GeorgeM

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

---

Posted at 2021-05-20 by GeorgeM

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.

---

Posted at 2021-05-20 by @allObjects

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).

---

Posted at 2021-05-20 by GeorgeM

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.

---

Posted at 2021-05-21 by @allObjects

@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.