X/Y display for a MCU

[coppercone2]

While it started as a half joke I can't get it out of my head. These chips have multiple DAC's on them.


Instead of messing with a LCD, it seems possible to make a port that you can hook up to a scope to have the MCU display something, like a ADC readout, on the X Y plot of a oscilloscope.


Has anyone ever seen a project like this? Say a simple one like show temperature on a oscilloscope from a PIC reading a temperature sensor.

https://www.mjoldfield.com/atelier/2015/08/xy-scope.html

[tggzzz]

This kind of thing? Tektronix Logo and Wizard Demo Generator for Oscilloscope with Table Tennis https://www.ebay.com/itm/116498624308

Or use a PC's sound card, and play the appropriate music through each channel.

[coppercone2]

I know you can do it with advanced things like sound cards, but has anyone done it with a MCU using the onboard stuff. so its a option you can pick for prototyping rather then putting on a display, like a library you can install to just make a project scope compatible

but that is exactly what I mean the tektronix display to show temperature or date/time

perhaps it could be standardized to use a display device like a 'access tuner ' , a simple little low frequency xy scope

[MarkF]

[coppercone2]

Hmm he uses GPIO. But there are many MCU that have multiple often unused DAC's. At least it shows its possible. GPIO uses too much parts and board space. I wonder how low parts count you can get it with some of those feature loaded chips.


I think it should be a display option in a <library>

so you can poll a ADC then post reading to display library

[ledtester]

Reminds of the AVR O-scope clock:

http://www.dutchtronix.com/ScopeClockH3-1-Enhanced.htm

Used a dual 8-bit DAC - external, of course, since the old AVRs didn't have them.

[coppercone2]

331 results found for 2 or more dacs from PIC

https://www.microchip.com/maps/microcontroller.aspx


How many bits do you think it needs minimum?

[cunningfellow]

depends what resolution you want.

Atari vector games (Asteroid Tempest etc) had 10 bit dacs for 1024x1024 addressable points.

Dutchtronix used 8 bits.

You choose how smooth you want it.

(Atari also had analog integrators and stuff to make the edges smoother but that then gets complex)

[coppercone2]

Hmm you can probobly make modified characters for low bit legibility, with a legend

[SiliconWizard]

Problem is it's not gonna leave much processing time for anything else, but otherwise that's fun.

[coppercone2]

Maybe they should add a special coprocessor for Xy displays!

[Martian Tech]

Slew rate is an issue.  If the slew rate of the X and Y DACs is the same and ∆X ≠ ∆Y then whichever is smaller will reach its terminal value sooner and you'll get a dogleg in your vector.  If you stick to multiples of 45° angles then you won't have a problem.  Also, you really need the outputs to change simultaneously so one axis doesn't get a head start over the other...  But in any case, it's fun to play around with, so don't be discouraged by what I say

As for processing time, that is more a factor of the persistence of the phosphor (assuming output to a CRT of some sort) than anything else.  You can draw a vector, turn off the beam (or even lift the pen on a plotter) and just let it sit there while you're computing the next vector.  As long as all the previous vectors you've drawn don't fade away you've got time for processing.  If you need a LOT of processing time then a storage scope might be called for 

[PCB.Wiz]

Reminds of the AVR O-scope clock:

http://www.dutchtronix.com/ScopeClockH3-1-Enhanced.htm

Used a dual 8-bit DAC - external, of course, since the old AVRs didn't have them.

That's seriously cool. 
The challenge is to keep a constant linear velocity, so that the drawing is all the same brightness.
On modern digital scopes, it does not look quite so neat.

It's a shame there is no modern CRT replacement.

More practical alternatives could be the Persistence of Vision designs, some look quite good, others not so much...
They have a similar time limit on display refresh rates, but the CRT approach has no air noise.

https://hackaday.com/2010/03/20/pov-clock-inside-acrylic-block/

https://www.aliexpress.com/i/1005006655301386.html

https://www.elektormagazine.com/labs/high-end-propeller-clock-120732

Here, he makes a great point about spin rate and air-noise, so two blades are better than one.

On my previous prototype, i found that the propeller had to run at more than 3000t/min to offer a sufficient refresh rate, but this made air noise. With this double refresh, I'll be able to reduce at only 1500t/min without any flickering effect. The propeller contains 2 infrared sensors at each extremity to give a mechanical position reference. This propeller is then able to display a 25*128 dot bicolor round matrix.

You could also shift the LEDs to interlace them, gets finer resolution but refresh is compromised a little.
A PAL TV used 50Hz frame sync and 15625 line rate, a LED POV clock could be quite similar, with 50Hz and 18000 'line' rate, for 1 degree refresh.

[Analog Kid]

https://www.elektormagazine.com/labs/high-end-propeller-clock-120732

Very interesting project.
But boo, hiss: they want me to register in order to look at any of the pictures?
I hate that. Just make them available to anyone, like on here.

[peter-h]

This has been done since the 1970s in oscilloscopes. Lots of TTL logic for the character generation.

Probably best done by using DMA to feed a timer-triggered DAC to feed the values at the correct rate. Then when you do a "printf" to some text buffer, that calls a function which generates a table of DAC values. With two DACs you can write anything

The reality however is that you can drive an LCD via SPI and the displays are dirt cheap - a few $
https://www.eevblog.com/forum/projects/graphics-on-an-embedded-system-tft-display-need-help-with-some-pointers/

[SiliconWizard]

Maybe they should add a special coprocessor for Xy displays!

For the RP2040 and 2350, that could be "accelerated" using the PIO and one of the two cores.
Not sure it's very useful these days, but it's fun.

There are kits to turn a CRT monitor into a vector display: https://www.retrorgb.com/vector-monitor-xy-kit.html

You can find old vector monitors otherwise. Or analog scopes.
The XY mode in most digital scopes usually sucks for this kind of purpose.

[David Hess]

Slew rate is an issue.  If the slew rate of the X and Y DACs is the same and ∆X ≠ ∆Y then whichever is smaller will reach its terminal value sooner and you'll get a dogleg in your vector.  If you stick to multiples of 45° angles then you won't have a problem.  Also, you really need the outputs to change simultaneously so one axis doesn't get a head start over the other...  But in any case, it's fun to play around with, so don't be discouraged by what I say

Tektronix used an integrator within the feedback loop of the vector generator to make the slew rate proportional to length.

This has been done since the 1970s in oscilloscopes. Lots of TTL logic for the character generation.

There was plenty of TTL logic state machines, but for Tektronix readouts, the character generation was initially analog with literal analog ROMs.  Later these were replaced with a couple of different digital methods of character generation.

[ledtester]

Another approach is to use "circle graphics" to produce very smooth curves.

This is probably the original design:

http://www.cathodecorner.com/sc200c.html

and this page describes the theory of operation:

http://www.cathodecorner.com/sc200theory.html

Other implementations:

https://www.sgitheach.org.uk/scope2.html

and

https://oscilloclock.com/

[tggzzz]

There was plenty of TTL logic state machines, but for Tektronix readouts, the character generation was initially analog with literal analog ROMs.

Yes, and that's a wonderfully imaginative solution from Barrie Gilbert. He invented a few other seminal devices too

His patent https://patents.google.com/patent/US3651510A
Description https://vintagetek.org/wp-content/uploads/2022/08/Simplifying-CRT-Character-Generation-Electronics-12-22-1969.pdf

[Siwastaja]

Why not?

For example nearly every cheap STM32 chip has two DAC channels capable of 1MSPS IIRC. And that can be driven with DMA to reduce CPU overhead.

Depends on what you exactly want to draw, but 1MSPS is already more BW than what you get out of sound cards; as tggzzz pointed out, people have done some fancy stuff even with those.

[mark03]

Another approach is to use "circle graphics" to produce very smooth curves.

I was curious what was going on here, so I skimmed the linked theory of operation.  It's an awfully convoluted way of achieving what you could do with basic X/Y DACs, except he uses a bunch of analog hardware instead   I don't see the point.  You just need to define characters with nice curves in a vector format, then, well, just do it.

I guess storing the screen elements in terms of lines and constant-radius circles makes for a very compact font definition, but nowadays, it seems like a lot of effort for little benefit.

[ledtester]

...
I guess storing the screen elements in terms of lines and constant-radius circles makes for a very compact font definition, but nowadays, it seems like a lot of effort for little benefit.

Well, the project was published in 2008 and used a Motorola HC908 microprocessor.

Also, the https://www.sgitheach.org.uk/scope2.html page has this to say:

What makes this type of clock special is how the image is created. Many other scope clocks (including my own scope clock 1) use a pair of DACs to drive the CRT deflection amplifiers directly. Objects (lines, circles, arcs) are created by varying the DAC output in steps to move the beam about. Such displays can be "pixelated" in appearance - straight lines can appear with "jaggies". The design by David Forbes uses sine and cosine signals applied to the deflection amplifiers to generate a completely smooth and round circle (lines, arcs, ovals are generated in a similar manner). Such a display technique creates objects with no digital effects, pixelation, jaggies etc.

[David Hess]

There was plenty of TTL logic state machines, but for Tektronix readouts, the character generation was initially analog with literal analog ROMs.

Yes, and that's a wonderfully imaginative solution from Barrie Gilbert. He invented a few other seminal devices too

I know of three methods Tektronix used for their readout on vector CRTs.

The first was Barrie Gilbert's function fitting with analog ROMs; a series of strokes are made by applying ramps to a series of translinear functions.  The last was to generate a raster with character matrix.  There was a third method, which I think looks better than a raster, where a digital ROM stored a series of linear strokes, producing something like a raster but without gaps between pixels.  I think this method made it into their early portable DSOs like the 2230/2232, but later portable DSOs use the raster method.

[tggzzz]

There was plenty of TTL logic state machines, but for Tektronix readouts, the character generation was initially analog with literal analog ROMs.

Yes, and that's a wonderfully imaginative solution from Barrie Gilbert. He invented a few other seminal devices too

I know of three methods Tektronix used for their readout on vector CRTs.

The first was Barrie Gilbert's function fitting with analog ROMs; a series of strokes are made by applying ramps to a series of translinear functions.  The last was to generate a raster with character matrix.  There was a third method, which I think looks better than a raster, where a digital ROM stored a series of linear strokes, producing something like a raster but without gaps between pixels.  I think this method made it into their early portable DSOs like the 2230/2232, but later portable DSOs use the raster method.

I wonder what was in the Tek 405x series of terminals. I used one briefly c1977/8, and was amazed at the clarity of the display - but I can't remember what the characters looked like, i.e. dot matrix or stroked.

All I can find is 6800 with 32k ROM and 8k RAM, with all ASCII characters, and individually addressable 1024x768 points. The latter just might be ambiguous in this context.

[mark03]

Well, the project was published in 2008 and used a Motorola HC908 microprocessor.

Also, the https://www.sgitheach.org.uk/scope2.html page has this to say:

What makes this type of clock special is how the image is created. Many other scope clocks (including my own scope clock 1) use a pair of DACs to drive the CRT deflection amplifiers directly. Objects (lines, circles, arcs) are created by varying the DAC output in steps to move the beam about. Such displays can be "pixelated" in appearance - straight lines can appear with "jaggies". The design by David Forbes uses sine and cosine signals applied to the deflection amplifiers to generate a completely smooth and round circle (lines, arcs, ovals are generated in a similar manner). Such a display technique creates objects with no digital effects, pixelation, jaggies etc.

But this just shows a lack of basic signals&systems understanding.  The stair steps at the output of a DAC are caused by spectral images at multiples of the sampling frequency (somewhat attenuated due to the zero-order hold), and are easily eliminated by oversampling followed with an RC low-pass filter.  Then the DAC + reconstruction filter provides a [near-] perfect translation of a bandlimited analog signal from its samples back to the analog domain.  You could just as easily use direct digital synthesis to get your sine and cosine signals before the DAC, although that is an unnecessary crutch.  Just figure out your desired smooth trajectory in X/Y space, and well, do it.  No magic necessary.  And all totally tractable in a 2008-era MCU, although perhaps not that one.