It was a most controversial topic in our team. Should programs make changes only along with pulses or not.
Some say “Why can’t I simply link a value to my LED and get it brightness updated automatically right at the moment when the value is updated?”
Others say “That’s a good idea to explicitly control when things change so that a nuke can’t be launched accidentally”.
Looks like a challenge between casual experience and academic accuracy. What do you think about the update-on-pulse concept?
The way I see it, it’s not a matter of casual experience vs. academic accuracy but rather what you’re used to historically.
For those with a software background in embedded software or standard synchronous electronic circuits, the pulse idea will seem the most logical, and the way to go. On a microcontroller almost everything that has to do with IO is interrupt driven, and checking status flags becomes a routine. Both can be considered pulses. In synchronous electronic circuits, it’s self evident that data is latched at rising edges, and thus state only updates every clock cycle. There, the clock provides the pulses.
However, coincidentally, I happen to have written a thesis on the topic of asynchronous systems (in Dutch, sorry), and although it takes quite a change of mind to get into that logic, it makes just as much sense as synchronous (pulse driven) systems do.
For example, assume you’d want to use a potentiometer to dim an LED by PWM-ing it (if that’s even a word), and forget about microcontrollers for a second but think about how you would implement it on a breadboard instead. I’d use an LTC6992 PWM-controller, with an analog input voltage between 0 and 1V, generating a duty cycle between 0 and 100%. To implement such a circuit, I’d have to connect a potentiometer at 5V to a voltage divider (= scaling) to scale it from 0-5V to 0-1V, then feed it into the LTC6992. I then connect the PWM output of the LTC6992 to an LED, with a series resistor of course.
When turning the potentiometer, you’d expect the LED brightness to change instantly, right? There is no explicit “pulse” in this design: as soon as the potentiometer value is changed, the voltage divider is updated, then the LTC6992 is updated, and the LED brightness changes immediately. Most people would agree that it would be pretty ridiculous to put a flipflop between each block, and then clock them to update each value on the rising edge of artificially generated pulses.
Now assume you’d want to do the same with an Arduino Uno instead of an LTC6992. You read in the potentiometer as a 10 bit value with the integrated ADC of the Atmega328, then scale it from 10 bits to 8 bits with a bit wise shift, and feed the result into the 8 bit PWM controller driving the pin to which the LED is connected. In XOD you’d need at least 4 blocks (analog input, scaling, PWM controller, GPIO), connected directly to each other. In this application, it would seem awkward and unnecessarily complex to have it update-on-pulse.
I agree that the update-on-pulse concept allows for more advanced control, but it is a result of designing XOD with programming experience in mind, which is not necessarily the most logical. Put yourself in the position of a 10 year old who’s building an automatic watering system for a plant in his room, by connecting a humidity sensor and a solenoid valve to an Arduino. The kid wants the valve to open as soon as the humidity level drops below a treshold. Then it makes sense to sample the humidity sensor as fast as possible, i.e. keeping the ADC running continuously, evaluate its result continuously and control the valve if necessary. There would be no pulses involved.
Of course, if you’re an experienced programmer and/or engineer then you know that soil humidity doesn’t change very quickly, so you’d put a timer on it to generate interrupts (pulses) to check the humidity once every minute or so, and let the microcontroller do something else the rest of the time, or put it in sleep mode to conserve power. But if you know that much about electronics already, then you’d probably want to try coding instead of building your application with XOD.
TL;DR: for many youngsters, students, hobby users etc. the update-on-pulse concept is not the most logical approach to building an application with blocks in a visual environment like XOD.
Wow! That’s very very interesting thoughts. Thank you for sharing your mind!
I actually wrote down a comparison table of two systems (pulse driven vs “analog”) and that challenge completed with 5:5 draw. It’s quite biased on actual points I’ve chosen to compare them, but one point disturbs me a lot. It is their interface ambiguity in a case of non-idempotent effect nodes.
Consider a node that would send an SMS. SMS should know destination phone number and SMS text. In the case of pulses the obvious node interface would be three pins: phone (string), text (string), send (pulse), but in the “analog” system it’s not so obvious. If the node has phone and text pins, would SMS be sent when the text changes, or when phone changes, or when either of them changes? Or maybe, it should still have explicit send pin?
Thinking again and again, it seems that having an explicit pulse only for such “repeatable” effect cases could be a viable solution.
Reading the exchanges I am baffled about how much in a different world the developers of XOD are. The point made by articcynda is very much my belief: put yourself in the place of a 10yr old. They don’t care about the minutia of the data changing, what frequency, when to send it etc.
If one has to first understand the underlying design principles of the XOD tool before developing solutions with it, then it is a heavy start compared to other tools. It is OK to explain the Comp science related concepts that will help the student develop programming models. But it is another to thing to start talking about clocking frequencies and passing signals from module to module on a clock basis in order to create working code.
If the design and coding activities are so detailed, then there will be very little adoption by the true crowd using the SCRATCH or SNAP tools.I actually ended up in the XOD tool via both of these other GUI based development tools, and to some degree due to their lack of capabilities. But after just a few minutes of interaction, I am truly skeptical about being able to use it with a young child. We’ll see!
Also curious about the language support ability of the tool. Not everybody speaks English and tools like Scratch and Snap address this nicely.
@tguneysu Thank you for the feedback.
The more I think about your points, the more I’m sure you are right. Luckily enough it would be not a big deal to “hide” pulses from a user. Although it will break backward compatibility, it’s a compatibility to nothing.
I think we’ll do it very soon.
Fortunately, there is no backward compatibility to worry about since XOD is still in closed alpha anyway!
I understand the confusion, @nkrkv, and the example of the SMS being sent is actually a very good one, because it depends on the application which strategy would be preferable. So let’s elaborate it a bit further.
Example 1 You’re building a smoke detector that notifies you with an SMS to your phone when your house is on fire. You’d interface the smoke sensor block with a comparator block, comparing it to a reference value, and if that value is exceeded then you want to have the SMS sent.
As in the example of the previous post, you’d want to attach the smoke sensor (ADC) to a comparator (if conditional) directly in the analog way without using pulses: the microcontrollers samples the smoke sensor as fast as the ADC allows it, and the value is compared against the reference as fast as the microcontroller runs. But the output of the comparator must lead to a single SMS, not a continuous stream of SMS’es.
So this example combines both: a part that runs without pulses, and a part that requires pulses.
Example 2 You’re building a system for a farmer that monitors the humidity and temperature at a plot of remote farmland. You’re having an Arduino programmed with XOD on the farmland, equipped with SMS module, and a DHT11 combo temperature and humidity sensor, and another Arduino with SMS module and LCD attached to it in the farm house.
In XOD, the user starts off with a DHT11 block which outputs temperature and humidity. The temperature and humidity output are connected directly to the SMS module.
On the receiver side, the user starts of with an SMS module, and the data output of it is connected directly to the LCD module block.
For a 10 year old, this will be a completely logical approach: sensor data is transmitted by SMS and displayed on the LCD module on the other side. There are no pulses involved here! So how would the SMS’es be sent?! Well, that’s where the intelligence of the XOD compiler comes in, of course. It must be clever enough to understand what the user is trying to do, and build the system accordingly. For example, since temperature and humidity change slowly, code is generated that reads out the DHT11 only once a second (its max. sample rate), and only sends an SMS if the values changed since the last measurement (a form of differential compression). On the receiver side, the LCD keeps displaying the previous values until an SMS with new values comes in.
Behind the scenes there is quite a bit of code required, but keep in mind that for the user it doesn’t matter when exactly an SMS is sent! The described strategy doesn’t use pulses, as there is intuitively no need for them. For a 10 year old, it will seem like there is a “constant” connection between the sender and the receiver, just like an ethernet connection appears continuous although it also only works with data packets. So the kid may think of a continuous stream of SMS’es being sent from one Arduino to the other, while in reality only a change in sensor values triggers an SMS.
So I agree with @tguneysu, XOD needs to be intuitive to use for a 10 year old who just received his first Arduino for Christmas, but not necessarily for a programmer with 10 years of C++ experience.
@articcynda Very good points, thank you.
No questions for nodes like LCD or LED. They can be pulseless easily. We’ll do it.
It the example of SMS I think a good compromise would be a phone + text + send pulse and some UX mechanism to make it send on any input change easily. In this case, it would be quite obvious when a user would be charged for SMS sent (I would pay $0.02 for every minute if the temperature changes) and still keep thing “analog” enough.
The example of SMS is a more difficult one of course, since sending SMS’es costs money per transmission. There are several possible solutions. The pulses vs. pulseless discussion will always have supporters on either side, so an elegant possible solution would be to have a global “expert mode” function which unlocks pulses on all blocks to update them.
In version 0.11.0 we have addressed the complexity related to the pulses. They are still here as a type, but they are no longer required for nodes where they look counter-intuitive and superfluous.