Graph Toggling Pin

[Turgut Guneysu]

Hi John,

Unless I misunderstand what is happening, I believe the code / graph combo is not right.

‌

I was expecting to see 1sec of HIGH and then 1sec of LOW on the graph. Something like this:

‌

Instead we get a steady HIGH with a quick LOW toggle.

It behaves like the READ is forcing the pin HIGH !

I can graph using the loop above, BUT manually change the pin in a FOREVER Loop to TRUE and FALSE, and it works correctly.

‌

That’s how I got the second graph !

CURIOUSLY, this one also produces the same graph:

‌

However, if you remove the WAIT, then the signal graphs correctly !

‌

[John Maloney]

What you’re seeing isn’t necessarily wrong. Because there is no delay in the “read digital pin” loop, the input pin is constantly being switched to input mode. When a pin is in input mode, it isn’t driven either high or low by the microprocessor, and the voltage on it (and hence the digital value read) depends on what’s connected to that pin.

From what you’re seeing in this case, there may be either an external or internal “pull up” resistor that pulls the pin high by default. But even without such a resistor the electrical value might tend to drift to a “high” voltage level. Or, the voltage might persist at the last output level as you were expecting. But without anything actively driving the pin, its behavior is not well defined. What actually happens depends all sorts of electrical details that are hard to predict. For example, inductive or capacitive coupling between circuit board traces can influence its behavior.

It your goal is to create and then graph a square wave, you might use two pins connected together – one an output pin being toggled between high and low and the other an input being graphed.

What microcontroller are you using for this test?

[Turgut Guneysu]

I am using micro:bit.

I tried two pins as suggested and all is well !

I hate micro:bit auto setting pins. It causes a lot of headaches coming from Arduino environment. It is awfully hard to explain to kids what is going on in the background, because the processor/firmware decided to play SMART !

>>> By the way, what is the horizontal resolution or sampling on the GRAPH block?

Is it possible to stretch the sampling to allow uSec pulses to be more visible ?

Thanks.

[John Maloney]

The horizontal resolution is 1 sample. The time per sample is determined by how often the script calls “graph” (e.g. is there a “wait” in the forever loop that is doing the graphing). If there is no “wait” then the sampling rate is limited by the speed at which the laptop can read the incoming serial data.

I tried graphing on a bunch of Windows machines and found that some of them could not handle high data rates (and, in fact, would lock up). To avoid that issue, MicroBlocks defaults to a conservative estimate of the maximum data rate. However, if you have a newer laptop it may be able to process data much faster than the default limit. You can increase that limit (at the risk of locking up your serial port if you go too far) by selecting “set serial delay” from the MicroBlocks gear menu and picking a lower number. On my Mac, 5 seem to be as low as I can go. That will give you more than double the samples and thus let you see more detail in a rapidly changing signal. (To look at faster signals, such as the IR signal from a television remote control, you can capture a burst of samples into a list and then graph the captured values in non-real-time after the capture.)

[John Maloney]

Question answered.