Since I always get great feedback from this forum, I thought I'd post the lastest one from the set for
beginners that I've been working on for my teacher friends:
There are so many different kinds of sensors, that there is necessarily a lot missing from that post (like async serial). So there will be a Adding Sensors part 2 in the new year when I can grab the time.
Any feedback is appreciated (...including criticism!)
a typical photoresistor varies between 1kΩ in the light and about 10kΩ in the dark
LDRs can go from 100 Ohm to over 1 MOhm. Much greater range. For a typical application you determine the light/dark values by experiment.
You can squeeze more sensitivity out of the Arduino’s humble 10-bit ADC by changing to a lower internal reference voltage,
That's misleading. The two are different in more than the actual voltage.
The internal reference is when you need an absolute reference for sensors that produce an absolute output; the external reference is for sensors that produce an output that depends on Vcc like the LDR example.
Break beam sensors are typical examples of digital signals, not analog signals.
By consensus on this forum, the String class is to be avoided. Use c strings instead. It's a bit harder to work with but better teach that way first.
Much further down, talking about sensor libraries: it must be mentioned that most libraries will include a simple example sketch which is included with the dowloaded file, no need to go back to github for that. Usually these examples do no more than initialising the sensor and printing out raw readings, but that's exactly what you need to verify the sensor works and to get started with it.
Thank you once again wvmarle! I have edited the text in several places to include your suggestions.
I agree the bit about the internal aref is incomplete, as are many of other things in that post, and I was hoping that the link to page on how I used the technique for better thermistor readings would clarify it for people who were interested.
I've moved the break-beam example to the digital section. It should have been there in the first place, but in my head it was also part of the "emitter-receiver pairs" concept.
By consensus, the String class is to be avoided.
I Am aware, but our experience of teaching new users is that we can get away with strings at the early stages (per the example at https://www.arduino.cc/en/Tutorial/Datalogger ) and then introduce them to char arrays when they have a bit more programming experience.
This kind of step is quite challenging when you are learning it on your own; and I'm still trying to get a grip on pointer manipulation.
From my naive side of the isle, I have to ask "Why don't they just fix the compiler so dynamic memory allocation isn't a problem?" And if Strings cant be fixed, how hard could it be to implement a little memory defragmentation function?
Of course that's easy for me to say, since I know very little about programming...
If you like dynamic memory allocation (so never knowing exactly how much memory a task uses), use Python. I love (and often hate!) C++ on how directly you (have to!) manipulate your available hardware.
I have no idea on the internal workings on the String function, and use it a lot myself (on ESP8266 with heaps of memory). Due to the ESP8266WebServer library using String itself big time, it's practically impossible to avoid it. Many data is returned as String and I am having a remarkably hard time converting from String to string. Much easier to stick to String in those situations.