|  Author | Topic: Hummer Oscilloscope (Read 1,947 times) |
gmoon
Wizard's Apprentice
member is offline
![[avatar]](http://home.earthlink.net/~dgdtv/images/jaw.jpg)
![[homepage]](http://s4.images.proboards.com/buttons/www_sm.gif)
Joined: Mar 2006
Gender: Male 
Posts: 876
Location: Ohio, USA
|  | Hummer Oscilloscope
« Thread Started on Aug 19, 2006, 8:52pm » | |
More (SHT) 'Stupid Hummer Tricks'-- make an oscilloscope using the Hummer and AVR:
![[image]](http://home.earthlink.net/~dgdtv/images/cavr/oscillo1.jpg)
4 overlayed traces here: top 2 'sine-curve' traces are what happens when the ADC on the AVR is allowed to 'float'--no input at all. Straight line in middle is one channel of the analog joystick (no movement-- which also shows the relative amount of noise in sampling analog devices.)
The digital trace is actually the nIRQ signal from the Hummer itself-- which occurs ~ 60 per. sec. I have yet to really test the limits, i.e., max frequency for the ADC. It's currently set at about 250kHz. Should be able to go higher, but eventually with some loss of resolution.
nIRQ Thread ref:
http://jledger.proboards19.com/index.cgi....read=1147911287
I used the simple bitmap graphic basic code from the Prog Ref, so the graph is inverted (easy to compensate, but I haven't, yet.) So the top is 0v, bottom 3.3v. The nIRQ pulses actually pull LO.
The data is /2, since the vertical res of the screen is only 200 (yes, I could have used a float instead.)
![[image]](http://home.earthlink.net/~dgdtv/images/cavr/oscillo2.jpg)
The code was a very simple addition to the cAVR code: just a free-running ADC read (8 bits) into a 256 byte buffer (ATmega8 has 1K ram--I doubt even 1/3 of that is needed for the existing code, so a larger sample is possible.)
The image above illustrates that the 'binary transfer' routine is currently hard-wired to use scrn memory--it dumps the data directly to $0680 (1664). So the pixels are mapped and then the scrn mem buffer is erased--the actual bitmap is @ $2000.
![[image]](http://home.earthlink.net/~dgdtv/images/cavr/oscillo3.jpg)
This is how the standard 'binary transfer' looks in the cAVR 'demo' program. Screen mem is just a convenient buffer--it's easy to instruct the system to dump the transfer somewhere else. This image is here to show the scrn dump is in the same place...  With or without the bitmap graphics.
If I get a chance, I'll rig up a 555 timer an some other stuff, see how that displays. There's currently no buffering, amp or filtering on the input.
[EDIT]
Looking at the 'floating' traces, where the ADC has no input and cops a 'natural bias', what's obvious is the effect of noise from the 60Hz line on the power supply. The curve isn't synced with the nIRQ, but the peaks and troughs are equal in period to the interrupt, so they also are occuring at 1/60 sec intervals.
Kinda cool to be able to see that....
| |
|
David Murray
Moderator
member is offline
![[avatar]](http://galaxy22.dyndns.org/david-avatar.jpg)
Joined: Dec 2004
Gender: Male
Posts: 1,561
Location: Kennedale, TX
| | Re: Hummer Oscilloscope
« Reply #1 on Aug 19, 2006, 8:58pm » | |
That is pretty nifty. Believe it or not, I had thought about doing the same thing with the onboard ADC once you got it working.. but as I didn't really have a use for it, I never did.
| |
|
gmoon
Wizard's Apprentice
member is offline
Joined: Mar 2006
Gender: Male
Posts: 876
Location: Ohio, USA
| | Re: Hummer Oscilloscope
« Reply #2 on Aug 19, 2006, 9:08pm » | |
Quote:| That is pretty nifty. Believe it or not, I had thought about doing the same thing with the onboard ADC once you got it working.. but as I didn't really have a use for it, I never did. |
|
I originally thought about the onboard ADC, too. But the limitations are pretty severe:
1) Resolution limit of 25kH @ 8bits (vs. AVR 200kH @ 10bits--if you don't mind dropping the resolution to 8bits, probably 500kH to 1mHz)
2) No transfer bottleneck--data is all buffered on the AVR itself, then transfered in a block after the sample.
As for me I'd LOVE to have a decent 'scope, but can't justify the expence... 
| |
|
gmoon
Wizard's Apprentice
member is offline
Joined: Mar 2006
Gender: Male
Posts: 876
Location: Ohio, USA
| | Re: Hummer Oscilloscope
« Reply #3 on Aug 20, 2006, 11:56am » | |
Due to an error in the AVR code, the previous images were sampling at only 125kHz (not 250.) So of course I had to try increasing the rate even more:
1mHz sample:
(2 overlayed: nIRQ pulse and the unconnected ADC 'float')
![[image]](http://home.earthlink.net/~dgdtv/images/cavr/osc1mhz1.jpg)
The vertical axis has been flipped, and the vertical resolution increased to /1.5 . Total # of samples taken increased to 320 (scrn width.)
After several tries to capture the nIRQ signal and failing, I realized that I was triggering the ADC loop from the very device I was trying to sample. The time gap was always going to be the same  .
So I inserted a delay loop until I got it....
Note about sampling rates: I'm not yet sure how the sample rate translates in to 'real world' frequencies--
1) the rate is adjustable, but there are delays while sample is taken--and while each individual sample is saved to RAM. The overall speed can still be increased even with the ATmega8L, by doubling it's clock speed to 8mHz (beyond that, a different chip is needed.)
2) I seem to recall (from audio work) that the actual sample rate is 1/2 the ADC rate.
Anyway, here's the AVR GCC code (GPL):
(the binary transfer routines are in previously released code, and not included)
Code:// oscilloscope
// sample ADC multiple times, fill array
// changes ADC to free running for sampleing
void do_oscillo(void)
{
uint16_t i;
ADMUX = 5 | _BV(ADLAR); // Select input pin and left adjust result--convert to 8 bit
ADCSRA = _BV(ADEN) | _BV(ADPS1); // 4Mhz/4 = 1mHz
for (i=0; i < MAXOSCVALS; i++)
{
ADCSRA|=_BV(ADSC); //start conversion
while(!((ADCSRA&_BV(ADIF))>>ADIF));
osc_data[i] = ADCH;
}
} |
|
MAXOSCVALS is 320
osc_data[] is an array of bytes, MAXOSCVALS in size.
Other constants are AVR specific....
The sampling is triggered by a new EXTCMD (EXT_OSCILLO_SAMPLE -- probably rename it EXT_MULTI_SAMPLE, since it's uses won't be limited to the 'scope.) For this to be useful, a pin-driven trigger needs to be added.
| |
|
gmoon
Wizard's Apprentice
member is offline
Joined: Mar 2006
Gender: Male
Posts: 876
Location: Ohio, USA
| | Re: Hummer Oscilloscope
« Reply #4 on Aug 20, 2006, 6:38pm » | |
More waveforms sampled with this setup:
First is the NTSC video output of the Hummer:
![[image]](http://home.earthlink.net/~dgdtv/images/cavr/oscwave01.jpg)
I never thought I'd get anything usable from the video output--maybe this isn't just a curiosity, after all...Not that it can compete with a real 'scope, but it may have it's uses.
Maybe I should order an ATmega88-- 20mHz clock at 2.7v (ATmega8L tops out at only 8 mHz--the price you pay for using 3.3v supply with the older chips.) Clocking @ 20 mHz and writing the save-to-ram loops in ML might equal or exceed a true 2mHz sample rate...
---------------------------------------
Last two are SID audio samples:
#1: low-freq sawtooth (WOW is this noisy--no audio fix here!)
![[image]](http://home.earthlink.net/~dgdtv/images/cavr/oscwave02.jpg)
#2: Higher-freq sawtooth from SID
![[image]](http://home.earthlink.net/~dgdtv/images/cavr/oscwave03.jpg)
All the samples taken at the 1mHz ADC frequency. I should cross-check the SID setting with the graph, to get a better idea of the approx sampling period.
| |
|
gmoon
Wizard's Apprentice
member is offline
Joined: Mar 2006
Gender: Male
Posts: 876
Location: Ohio, USA
| | Re: Hummer Oscilloscope
« Reply #5 on Aug 27, 2006, 7:34pm » | |
Despite not having much time these days for hacking here's an update:
Original images were processed in BASIC (2-5 minutes per screen!) Despite the technical challenges remaining, once or twice per second is a big improvement.
View some video:
Hi-freq sample--NTSC video signal:
http://video.google.com/videoplay?docid=-6050699817557174029
(hi freq sampling badly needs that double-buffering)
Realtime sampling w/scrolling:
http://video.google.com/videoplay?docid=8494931415985517786
Sampling SID (both realtime & hi freq included):
http://video.google.com/videoplay?docid=7092675012171514797
Used Stephen Judd's 'grlib' code for the hires line drawing ( http://www.ffd2.com/fridge/ .) Linedrawing is one of the biggest bottle necks here--but in fact only vertical lines need to be drawn for this type of display, which should be much faster (so I'll get to that soon.) The ML bitmap scroll routine is my own--and I'll try it using DMA next (scrolling is also a bottleneck.)
To make the realtime sampling consistent, it should be IRQ driven (on the AVR.)
Haven't gotten the grlib double-buffering to work yet (but I haven't spent much time on it either.) That will make the hifreq mode much easier to view.
Flipping/scaling the input is all done on the AVR now, to offload some processing from the DTV. It's all fix-point scaled to a range of 0-175, which is a good compromise between 128 and 200.
Couple of other possible future improvements:
1) Capture, draw, then animate the hi freq samples. Plenty of RAM for buffering frames.
2) Use DTV 8bbp graphics mode. As this is indexed color, draw over previous samples with an incremented value, then change color index so last drawn trace is bright; previous traces gradually darken. No need to erase between traces. Allow perhaps 8 traces to be visible simultaneously. After the whole color range range is exhausted, start over again (possibly adjust existing traces/colors down to minimum values, and continue as before.)
| |
|
gmoon
Wizard's Apprentice
member is offline
Joined: Mar 2006
Gender: Male
Posts: 876
Location: Ohio, USA
| | Re: Hummer Oscilloscope
« Reply #6 on Aug 27, 2006, 7:48pm » | |
It's pretty rough, but you can look at the code anyway....
http://home.earthlink.net/~dgdtv/dtv/cavr64/oscil_1c.asm
Assembled with 64tass-1.45 . Minimal interface, graphics routines, etc, with cAVR protocol code tacked on the end. Load as a BASIC prog.
The video actually looks pretty crappy--when the screen changes brightness, the camera over-compensates for the exposure change.
I was thinking of changing the display to light-on-dark anyway.
| |
|
David Murray
Moderator
member is offline
Joined: Dec 2004
Gender: Male
Posts: 1,561
Location: Kennedale, TX
| | Re: Hummer Oscilloscope
« Reply #7 on Aug 27, 2006, 9:49pm » | |
Pretty nifty. There have been times I could have used something like that.
If you used the regular 1-bpp linear graphics mode combined with the DMA, I bet you could get some really smooth scrolling there.
| |
|
gmoon
Wizard's Apprentice
member is offline
Joined: Mar 2006
Gender: Male
Posts: 876
Location: Ohio, USA
| | Re: Hummer Oscilloscope
« Reply #8 on Aug 29, 2006, 8:28am » | |
Quote:| If you used the regular 1-bpp linear graphics mode combined with the DMA, I bet you could get some really smooth scrolling there. |
|
I hadn't considered a linear mode with 1bit graphics. Hmmm. Time to dive into the prog doc...
Incidentally, the 1st and 3rd (SID, second half) videos above give a good demo of the transfer speed of cAVR protocol's 'binary transfer' mode--256 bytes per transfer (actually 256x9 bits but I haven't written code to use that extra bit . And all 9 bits are used in other modes--a normal ADC read--but not in the oscilloscope project, 'cause the values must be truncated for the 200 pixel vertical dimension anyway.)
Each block of data transfers while LED is lit, so that's a good indication of the speed (still haven't done any benchmarks.) It's not limited to 256 bytes, that's just how it's setup for this app.
One other note:
By mistake, I left this thing running in realtime mode yesterday for about 14 hours. Never lost sync, still bangin' away. The AVR was stone cold, but the Hummer's ASIC blob was pretty warm...
Even if you could overclock this thing (new xtal?), it might be a bad idea.
| |
|
gmoon
Wizard's Apprentice
member is offline
Joined: Mar 2006
Gender: Male
Posts: 876
Location: Ohio, USA
| | Re: Hummer Oscilloscope
« Reply #9 on Aug 31, 2006, 8:04am » | |
Quote:| If you used the regular 1-bpp linear graphics mode combined with the DMA, I bet you could get some really smooth scrolling there. |
|
Sticking with the standard VIC bitmapping mode, but using the DMA with modulo works just fine--no need for linear mapping. It's particularly slick to use a zero step/no src modulo for your DMA source when you want to copy one byte -> many bytes (like a scrn clear or block fill--patterns would be easy, too.)
I haven't encountered the dma/modulo bug described by tlr, but the modulo/linelength settings are a little quirky. I wonder if this DMA issue was fixed in DTV "V3" (Hummer)....
| |
|
David Murray
Moderator
member is offline
Joined: Dec 2004
Gender: Male
Posts: 1,561
Location: Kennedale, TX
| | Re: Hummer Oscilloscope
« Reply #10 on Aug 31, 2006, 8:11am » | |
Quote:| It's particularly slick to use a zero step/no src modulo for your DMA source when you want to copy one byte -> many bytes (like a scrn clear or block fill--patterns would be easy, too.) |
|
Yes. I used this in my 256-color graphics routines a lot. I think it was you or TLR who suggested I use it. After thinking about it I went "duh, why didn't I think of that?" so I changed all the fill routines to use step-0. It is very fast. It can clear the entire 64K area of the 256-color screen in the blink of an eye.
| |
|
gmoon
Wizard's Apprentice
member is offline
Joined: Mar 2006
Gender: Male
Posts: 876
Location: Ohio, USA
| | Re: Hummer Oscilloscope
« Reply #11 on Aug 31, 2006, 8:22am » | |
Quote:| Yes. I used this in my 256-color graphics routines a lot. I think it was you or TLR who suggested I use it. After thinking about it I went "duh, why didn't I think of that?" so I changed all the fill routines to use step-0. It is very fast. It can clear the entire 64K area of the 256-color screen in the blink of an eye. |
|
I'm sure that was tlr, since I'm just now playing with the DMA for the first time. It sure is wicked fast.
I looked at your code again this morning to see how much was DMA and how much was 65xx. You might try the modulo to draw your boxes in one go....
| |
|
gmoon
Wizard's Apprentice
member is offline
Joined: Mar 2006
Gender: Male
Posts: 876
Location: Ohio, USA
| | Re: Hummer Oscilloscope
« Reply #12 on Aug 31, 2006, 8:40am » | |
Here's a little dma/modulo code for clearing the right side (64 pixels, 24 chrs deep) of a std bitmap:
;---------------------------
; clear rt side of scrn with dma
clrdma
;-----dma---------
lda #$01
sta $d03f ; enable extended registers
lda #$02
sta $d31e ; use dest modulo only
ldx #(clrdataend - clrdata - 1)
clrdma1
lda clrdata,x
sta $d300,x
dex
bpl clrdma1
lda #$0d
sta $d31f
clrdma2
lda $d31f
lsr
bcs clrdma2
;-----dma end-----
rts
clrdata .word clrbyte ; src RAM
.byte $40 ; src RAM hi
.byte $00, $e1, $40 ; dest RAM
.byte $00, $00 ; src step
.byte $01, $00 ; dest step
.byte $00, $06 ; dma leng
.byte $00, $00 ; src modulo
.byte $01, $01 ; dest modulo (amt + 1)
.byte $00, $00 ; src line len
.byte $3f, $00 ; dest line len (leng - 1)
clrdataend
clrbyte .byte $00
| |
|
gmoon
Wizard's Apprentice
member is offline
Joined: Mar 2006
Gender: Male
Posts: 876
Location: Ohio, USA
| | Re: Hummer Oscilloscope
« Reply #13 on Sept 6, 2006, 6:55pm » | |
More video of Oscilloscope hack:
All these examples use DMA with modulo (except the full screen clr, which is contiguous mem, and doesn't need the modulo.) You might compare these videos with the last batch so see the scrolling speed increases (DMA vs. ML.)
1) Realtime with block (partial screen) DMA/modulo scrolling
http://video.google.com/videoplay?docid=5602124406226819253
2) Buffered Hi frequency sampling,with a double-buffered screen and DMA erasure of hidden buffer.
http://video.google.com/videoplay?docid=8624651050952338384
3) Realtime DMA/modulo scrolling, fullscreen:
http://video.google.com/videoplay?docid=-8474042085084037895&hl=en
Video #1 demos using DMA/modulo for scrolling only part of the bitmap. First the screen is filled with a bit pattern to help illustrate that the whole screen isn't scrolling. It scrolls left 8 pixels/scroll (one chr width.) (It looks like it's scrolling twice for every draw, but I think that's an artifact of the video/CRT scrn. I'll check it out more closely, though--the speed make's it tough to see. I might try enabling the V Blank Start for the DMA transfer.)
Video #3 scrolls by 64 pixels.
I've now learned a bit about the DMA/modulo. At this point, scrolling with a bitmap is limited to 8 pixel jumps. To remove this restriction:
1) use linear bitmap addressing
2) or use the blitter, which should be able to bitshift.
3) or use the blitter AND linear addressing
I intend to play with all options, using the blitter both with the newer screen modes, and the older VIC modes. The blitter will make it faster, anyhow.
I spend several hours tracking down what I thought was a bug. Turns out it was a documention error in Stephen Judd's GRLIB routines: MODE is set by X reg, not A reg. Of course, I'd love to start using the Blitter for line drawing .
All these Oscilloscope video files use the SID output of the Hummer as a signal source. If you look closely, you'll see sawtooth, triangle and pulse.
I'm planning on developing this hack further, but I've got other toys and other ideas. This one will be on the back-burner, and revisited from time-to-time.
| |
|
David Murray
Moderator
member is offline
Joined: Dec 2004
Gender: Male
Posts: 1,561
Location: Kennedale, TX
| | Re: Hummer Oscilloscope
« Reply #14 on Sept 6, 2006, 8:54pm » | |
Quote:| I'm planning on developing this hack further, but I've got other toys and other ideas. This one will be on the back-burner, and revisited from time-to-time. |
|
Yeah.. That is actually very cool. I watched the videos. I'd love to see it in real-life. Unfortunatly, my time is limited too, and building this contraption is on the back-burner for me... Since it may well be 6 months to a year before I'm ready to start putting any electronic items in my shuttlecraft.
I was thinking of writing a little game like tetris, pong, or "LCD Bros." (think super-mario) to work on my LCD screen using custom-generated characters. However, I'm surprised how little interest it has generated in the community.. so I'd be the only one ever playing them. So I think I'm going to put this project on the shelf now that I finished my ML driver. I guess it is time to move on to something else.
| |
| |
|
![[Home]](http://s4.images.proboards.com/menu/home.gif)
![[Help]](http://s4.images.proboards.com/menu/help.gif)
![[Search]](http://s4.images.proboards.com/menu/search.gif)
![[Login]](http://s4.images.proboards.com/menu/login.gif)
![[Register]](http://s4.images.proboards.com/menu/register.gif)
![[Search This Thread]](http://s4.images.proboards.com/search2.gif)
![[Send Topic To Friend]](http://s4.images.proboards.com/buttons/sendtopic.gif)
![[Print]](http://s4.images.proboards.com/buttons/print.gif)
Logged