Posted on
• 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
=0.41113908598
=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.