H2: Available GPIOs under Windows

[mad_ady]

Yes, I know... You wouldn't expect me to touch windows, but hey, life is complicated.

Background information: My older kid is using an H2 as a "gaming PC" (a better one is in the project pipeline...). Anyway, because he's a kid, he also has time restrictions (https://github.com/mad-ady/mqttNanny). Thanks to my home automation, he gets audible notifications when there is 10 minutes left, 5 minutes, 1 minute, so that he can save his progress (or panic, if the game has fixed checkpoints). The problem is, during the summer vacation he'll be going to his grandparents, and there will be no notification. So I thought, I'll make a simple LED "semaphore" that shows him how close he is to lights out. And it needs to work under Windows!

Looking at the expansion port, the obvious choices are the two serial RTS pins: https://wiki.odroid.com/odroid-h2/hardw ... o#tab__h21
I've tested, and they can be toggled from within python (under windows), just by opening and closing the serial port.

But sadly, there are only two pins, and I have 3 leds... For now, I've hooked the green led to a serial TX line, and it keeps it lit all the time (If I send traffic, I can see a blink effect, but it's a bit too faint). When time goes below 10 minutes, I turn on the yellow led by closing the port (it's on by default). When time drops under 5 minute, I close the other serial port and the red led turns on. For the "less than 1 minute" part I chose to run a thread that blinks the leds every second. That should get his attention!

So, if you're looking for 2 general purpose GPIO pins, you can fake it with windows and pyserial by opening and closing a serial port.

I wonder if there are other pins that could be repurposed...
I'll share a pic of the semaphore working once I've rebuilt it and attached it to the case. Making it pretty (and secure) will be a challenge...

P.S. It seems hooking up 3 leds with a single resistor is a bad idea: https://www.allaboutcircuits.com/techni ... r-or-many/, so I can't simplify the PCB...

[mctom]

Honestly this thread needs a better title, I almost missed that because it looks so uninteresting.

There's plenty of possibilities!

The craziest and hackiest of them all is to use your two existing pins to write data into serial-in parallel-out shift register. One pin is a clock, and another is data. On every rising edge of a clock, whatever logic state is available on data pin is saved on bit #0, and all preexisting data shifted right. All 8 bits stored in the register are exposed on separate pins at all times.
You can clock in 8 bits and drive 8 LEDs independently using 74164, among many standard TTL chips that could do that. Hey, I even found a schematic. It's a schematic from forum question, not an answer, but reflects the idea.
"A" and "B" pins are data input, long story short they can be tied together. CLK is obvious, and CLR resets the whole register into 0x00. May be safely ignored and tied to GND.



Frankly, this is how PiStackMon works. LED driver is the same type of shift register, except is 16 bit and has constant current outputs, so you can connect LEDs without resistors to save space. So yeah, a serial LED driver would be even better, if you're still up to this crazy idea.
I bitbang control signals in PSM, as it has no minimum clock frequency (what we call "fully static operation").

Less crazy idea involve USB to GPIO "adapters", with Microchip solutions being on the lead, I think. For example MCP2221 (I think I used it in some old design in previous workplace) "converts" USB to I2C, UART, and 4 extra GPIOs. I'm sure there are more advanced chips in this family, and ready-made dongles for purchase. There are Windows DLLs and example code to interface that chip. I drove it via DLL calls in LabVIEW IIRC.

EDIT: There should be some Python calls to drive that RTS line directly, I think?

EDIT2: Of course, I forgot FT232, FT2232 and similar chips also have programmable GPIO, and similarly to Microchip's thing should have DLLs and whatnot. And you may already own one.

[mad_ady]

Your solution is simple and elegant, thanks! You could probably drive a 7-segment display with it and show a countdown.

EDIT: There should be some Python calls to drive that RTS line directly, I think?

Just calling

Code: Select all

import serial

#turn off RTS
s1 = serial.Serial('COM1')
#turn on RTS
s1.close()

does the trick. It's probably handled by the driver.

[mctom]

I'm worried how fast it can get. If it turns the port on or off with 1s delay, that's gonna look like crap. You think you could loop these two commands and measure the output frequency?
Some digital multimeters can measure Hz, that'd do.

Actually yes, you can daisy chain multiple shift registers and drive a few 7-segment displays. All registers would use the same clock, but a data input of the next one would be hooked up to QH of the previous one. 7 segment displays are on the table if you want to go that way, but must be of a common anode type.

Actually, even one 7-segment display with countdown in minutes would be really nice.
I'd make it count from F to 0
Or a binary! What a perfect opportunity to teach a kid binary!

There are some dedicated LED drivers in DIP packages but all are out of stock.

So the "shortage edition" solution is this:
https://www.tme.eu/ro/en/details/74ls16 ... n74ls164n/
And the datasheet:
https://www.ti.com/lit/ds/symlink/sn54l ... 2419757088

The "LS" part here is important, because even though this chip requires 5V power supply, it still accepts anything above 2V as logic high input. So this should work with 3.3V logic present on H2 just fine.

One important thing to note about TTLs: Their outputs have much stronger current capabilities when pulling to 0V than 5V. This is also true for many digital outputs, such as in many microcontrollers.
So the usual way is to connect LEDs to +5V, via resistor, to TTL output. Then, setting TTL output to "0" will turn on the LED.

[mad_ady]

You think you could loop these two commands and measure the output frequency?

I'll try it on monday and dust off my oscilloscope. But I'm switching from python, so there's an overhead...

[mctom]

I used to have a lifestyle where workdays were days off

Well, you could also loop it 100 times and 200 times, and see the difference in execution time, assuming these "port on/off" calls block until the port is actually switched on or off.
If these calls are nonblocking then you may get rubbish output.
Either way, you'd better check that before you spend 5 RON on a chip!

[brad]

Only a thought but I bet you could drive a small piezo speaker from a single gpio relatively easily and create different tones (by varying the frequency of gpio switching) for the different notifications.

[mad_ady]

Thanks for the idea! That could work, though I don't know if I can just tie a speaker (I have one from a go-advanced) directly between a gpio and ground...

[mctom]

I really don't think you can turn a serial port on and off fast enough (and regularly enough) to drive a speaker. Yes, not to mention some amp stage for it, but perhaps one or two transistors would do.

[mctom]

I had some time to kill so I made a "infographic"

[mad_ady]

Thank you!
I have to admit, a digit as display is very tempting! It's barely within my hardware capabilities, and an interesting software design. I think I can source the parts locally, and could use the display to show other things too (e.g. a simple load meter).
I especially look forward to it displaying a countdown from F. That's how you become fluent in hex...

The problem is available time. Unless... I convince kid #1 to join me on the dark side and build it together. He kind of wants to learn more about computers (but isn't yet ready to sit down and listen). Perhaps a hands-on project will be more interesting!

[mctom]

The 7-segment display makes a lot of sense in this project, because you'll have everything you need to drive 8 LEDs anyway.
Don't feel intimidated by that, 7-segment display is just 8 LEDs in a single package, with all anodes or cathodes tied together. The schematic shows why you want the one with common anode in this case. I specifically select THT components for your projects so it's easy to build, and all of them should fit into a universal board with a standard 100 mils raster. With a good plan you'll build it all in 1 hour.
All these components should be available in your local shop. My local shop don't do requests like "7-segment display with common anode", they want part numbers only. So I always have to look up their online catalog and check which parts actually fit. But if that is the case, tme.ro might make more sense. Local shops are good to have if you need a specific resistor or capacitor value, something not worth buying online and waiting for a delivery. The main components for a project are mostly sourced online.

Just be mindful that because you only have two "GPIOs" at your disposal, you cannot strobe the output. So at the time you push new data into the register, the display will show nonsense. This is why it's important you measure the available output frequency, so it won't look like ass. While refreshing every minute, any frequency will do, in the worst case it will just show rubbish for a second or two. For displaying anything more sophisticated, you'd want at least 1000Hz, so the refresh of all 8 bits takes just 8ms. That is why I suggested measuring that before committing to any solution.
TTL chips process 1MHz easily, that's a rule of thumb.

I remember when my dad wanted to show me how transistor works, when I was 8 or so. Back then I had the best of times playing with a model train power supply, a car light bulb, a computer fan and a bunch of switches. Well, the presentation of an npn transistor was a flop - he couldn't remember which pin is which, and he wanted to use it to switch a light bulb on, something I already knew how to achieve with a mechanical switch. I didn't see a point back then, so I wasn't interested.
The point is, you're building a thing to tell your kid when the play time ends.. I don't see them interested in that. IF you built a display with an ammo/frag count, that'd be a completely different story!
Yes, you guys definitely need to do a project together, but maybe not this one. After all, this is a new territory for you, and you don't want to be that teacher who can't answer questions beyond the scope of a lesson.
And displaying hex values on a display that matters to a kid is definitely a great idea, it's an effortless opportunity to learn something new for them.
I used a binary watch ever since I got one for 18th birthday, you wouldn't imagine how fluent I got in binary within weeks.

[mad_ady]

Ok, I made a bit of time to do some measuring with my tiny oscilloscope.
The code runs under python3 with pySerial (presumably has some overhead) and consists of:

Code: Select all

import serial
red = serial.Serial('COM2') #or /dev/ttyS1

while True:
   red.close()  # 3.3V
   red.open()  # 0V

Under Windows 10 I get the following:

So - a ~10ms pulse with a period of about 60ms, that would achieve a frequency of ~16Hz. The pulse width is most of the time 10ms, but sometimes can drop to 5ms. CPU usage is around 5% (idle windows)

Under Ubuntu 20 I get:

So - a ~768us pulse with a period of about 1ms, that would achieve a frequency of ~1KHz. The pulse width looks constant to about 20% tolerance. CPU usage is 100% on one core, though...

So, an order of magnitude difference due to implementation.

[mctom]

Yeah, that's a lot of wasted CPU cycles, but that's the worst case starting point, which is still okay to refresh a 7-segment once a minute.

Some ideas for improvement

- https://pyserial.readthedocs.io/en/late ... Serial.rts <- they say there is a way to set RTS state directly, have you tried that? You may need to disable the hardware flow control for that.
- For clock line, you could actually use TX pin instead - just send 0x00 through that port, that should produce a single negative pulse (start bit). In the end only one port would be necessary, with its TX and RTS.
- If you freed one RTS line, you could in fact gain an extra GPIO, that could be used for latching - no refresh nonsense visible on the display, and also perhaps an actual LED driver could be used.
I'll look into that later today - right after I finish work, get a better cat food to make him eat his medicine, and reinstall a bathroom sink that fell off the wall today for no damn reason.

Oh, one more thing - the "low" state is wiggly which suggests it's not actually pulled low, but becomes floating instead (Not connected to anything). Makes sense as the default state of unused GPIO is to float.
That has to be taken into consideration in the design. TTL chips with floating inputs consider them "high" so the proposed circuit won't work. Thankfully I saved that one so I can modify it later.

EDIT: Err, are the voltage levels correct? That suggests the output is 1.2V...

[mad_ady]

Don't go overboard with designs just for me! Unless you get a kick out of it...

Code: Select all

they say there is a way to set RTS state directly, have you tried that? You may need to disable the hardware flow control for that.

I've tried it under Windows and it didn't toggle the GPIO. But opening/closing the port did.

EDIT: Err, are the voltage levels correct? That suggests the output is 1.2V...

I measured it at 3.1V. Might be something off in the software.

[mctom]

Hey no worries, I like designing 101 stuff.
And the sink is fixed! Hooray!

About RTS, you are aware that RTS goes low when it's set to True, right? At least it should

Here's how flipping RTS works on M1 (using Python).
62.5kHz! (In Doc Brown's voice)

DS1Z_QuickPrint1.png (41.02 KiB) Viewed 187 times

But I get it, maybe Windows forces the port to work in some weird mode or anything. Or just doesn't support RTS/CTS at all, or insists on hardware control.

Still, I think this could be nicely optimized:

- RTS of one UART port can be a data output
- Tx of another port could do clock pulses

The code could optimize the whole thing, as single byte written to Tx may have as much as 5 pulses
So, if you want to send 1-5 bits of the same value in a row, you'll do that in 1ms. (assuming 9600 link, but why not 115200?)
You may ignore the fact the pulses are negative, all TTL cares about is to see a rising edge and count it as a pulse.

DS1Z_QuickPrint2.png (46.96 KiB) Viewed 187 times

Yeah, let's ignore the squiggliness, I didn't bother connecting scope's ground properly.

The problem is that floating RTS pin when the port is disabled. We'll add a common-emitter buffer from AnyTransistor(TM). This will flip the logic states around, but that's not a problem.
TX is by default nicely driven by any compliant source so it won't require any buffering.