ATtiny85 VGA Sync

May 3, 2020 at 8:52 pm (computers, maker, Uncategorized) (, )

I’ve been reading Ben Eater’s inspiring series on producing a VGA video output from breadboards containing basic logic gates implementing counters, so wanted to see for myself how to create the timing signals for a VGA output.  There are loads of tutorials for how to produce VGA using an Arduino, with the main source appearing to be from Nick Gammon.  So for the sake of variety, I decided to see how it might work on an ATtiny85 (although naturally, many have also been there before too).

I’ve only implemented the sync signals to see if a monitor would recognise my signal.  I might see if I can get some data out at some point at some relatively low-level resolution.

The key decision is all centred around what clock frequency the ATtiny can support and how that relates to VGA video timings.  After a bit of messing around with a calculator, I settled on the following:

VESA Signal 640×480 @ 75 Hz and used the 64 MHz PLL clock mode of the ATtiny85 using a /8 prescaler – so a 8MHz clock, with each “tick” being 0.125uS.

So taking the timing values from the above linked tinyvga site, and translating that to “ticks” gives:

Scanline Pixels Time (uS) ‘Ticks’ @ 8Mhz
Visible Area 640 20.31746031746 16.546
Front Porch 16 0.50793650793651 4.063
Sync Pulse 64 2.031746031746 16.254
Back Porch 120 3.8095238095238 30.478
Whole Line 840 26.666666666667 213.333

Naturally there will have to be some rounding – I won’t be able to get fractions of a “tick” out of the ATtiny85 Timers.

This all rounds up to using the ATtiny85 Timer1 in PWM mode providing an output on OC1A to provide the H_sync pulse, then manually counting lines in the overflow interrupt routine to manually drive the V_sync pulse.

I originally wanted to use OC1B which made the pin assignments on the ATtiny85 much simpler, but ended losing an afternoon attempting to work out why I was getting no signal on OC1B. Turns out there is a bug in the ATtiny85 Compare on B for Timer1 – the compare mode bits in GTCCR are ignored unless the same bits are set for Compare on A in TCCR1.  Having found reference to this on the Internet, this kind of sounds familiar so I’m wondering if I’ve fallen foul of this before! Anyway, OC1A it is.

Pin assignments are as follows:

  • H_sync = PB1 (pin 6) OC1A
  • V_sync = PB4 (pin 3)

And the Timer1 settings are as follows:

  // Run a timer interrupt off a 64 MHz clock
  PLLCSR |= (1<<PLLE);            // Enable 64 MHz PLL clock
  while (!(PLLCSR & (1<<PLOCK))); // Wait for the PLL lock
  PLLCSR |= (1<<PCKE);            // Enable PLL as source for Timer 1

  // Timer 1 for CTC mode; set on compare with OCR1A; overflow interrupt
  TCCR1 = (1<<CTC1) |                // Reset on match with OCR1C
          (1<<CS12) |                // Prescale /8
          (1<<PWM1A) |               // PWM mode
          (1<<COM1A1) | (1<<COM1A0); // Set OC1A on compare; clear on rest
  GTCCR = 0;
  OCR1A = 15;
  OCR1C = 218;

There was some experimentation required to adjust the timings from the theoretical 213 ticks – 218 seems to give the most accurate horizontal sync frequency for some reason.  I haven’t done the maths to see why.  I was assuming I’d use 213 with a possible “leap tick” required every now and again to account for the lost 0.333 ticks to keep things in check, but turns out this worked ok for me instead.

Note that VESA 640×480@75Hz requires negative pulses, hence using “Set on Compare” rather than “Clear on Compare”.  Some modes require positive pulses so this would have to change.

The rest is just counting lines for the vertical refresh (using the line timings from tinyvga: 480-1-3-16=500), which is all done using the Timer 1 overflow interrupt, which signals the end (or in my case, start) of each horizontal line.

The final code is shown below, and sure enough, hooking this up to a monitor does indeed bring up the required mode to be recognised.

Next up, I’ll have a think about sending some data over.  Although if I want RGB outputs, that basically uses up the rest of the ATtiny85 I/O pins. That is an experiment for another day.

Kevin

// Use a ATtiny85 to output a VGA signal using
// its 5 output pins
//
//    (RST) ---------- | 1   8 | --------- (Vcc)
//    V_sync -- PB3 -- | 2   7 | -- PB2 -- R (0-0.7v)
//(0-0.7v) G -- PB4 -- | 3   6 | -- PB1 -- H_sync
//    (GND) ---------- | 4   5 | -- PB0 -- B (0-0.7v)
//
// NOTE: Wanted to use OC1B but there seems to be a bug in many ATtiny85 that
//       means that OC1B doesn't work properly unless OC1A has the same mode.
//       Consequently, using OC1A on its own to serve the purpose required.
//
// Note: Use ATtiny85 PORTB numbers
#define H_SYNC 1  // OC1A
#define V_SYNC 3
#define VGA_R  2
#define VGA_G  4
#define VGA_B  0

// Basic operating principle:
//  Timer configured to automatically create the H_sync pulses by using Timer 1
//  compare values.  H_sync needs to drop negative for a short pulse at the end
//  of each line.
//
//    <----- H pixel display ------><HFP><H_sync><HBP>
//
//  Or alternatively:
//    <H_sync><HBP><----- H pixel display -----><HFP>
//
//  Use Timer 1 to signal frequency of H_sync based on OCR1A.
//  Use Timer 1 OCR1A to specify duration of H_sync.
//  So attach H_sync signal to OC1A output.
//  Configure OC1A output as Clear or Set on Match as required
//
//    V_sync pulses are created by counting horizontal lines.
//    V scanning will be in one of the following modes:
//         In Display Area - hence H-scan is drawing pixels
//         In V front porch or back porch areas
//         In V_sync area
//
// VGA Timing Modes are taken from: http://www.tinyvga.com/vga-timing
//
// Based on the option of a 64 Mhz timing signal, choosing VESA 640x480 @ 75Hz
// gives us the following timing parameters
//
//     Screen refresh rate = 75 Hz
//     Verticle refresh    = 37.5 kHz
//     Pixel frequency     = 31.5 MHz
//
//     Timings are as follows
//      H visible area        640     20.31746031746 uS
//      H front porch          16      0.50793650793651 uS
//      H sync pulse           64      2.031746031746 uS
//      H back porch          120      3.8095238095238 uS
//      Total H line          840     26.666666666667 uS
//
//      H pulse is negative.
//
//      V visible area        480     12.8 mS
//      V front porch           1     0.026666666666667 mS
//      V sync pulse            3     0.08 mS
//      V back porch           16     0.426666666666667 mS
//      Total V frame         500     13.333333333333 mS
//
//      V pulse is negative
//
//  Using 64MHz PLL Clock as source for Timer 1 and setting Prescale to /8 gives
//  a frequency of 8 MHz and a single "tick" of 0.125 uS.
//
//  Total horizontal line timing is thus 26.666666666667/0.125 = 213.333 "ticks"
//  use 212 for OCR1C to define the line duration (same as the Timer 1 period).
//
//  At this resolution, H_sync is 2.031746031746/0.125 = 16.254 "ticks"
//  so use 15 for OCR1B to define the H_sync pulse.
//
//  As the required pulses are negative, need to use Set on Compare Match.

int V_Sync_Line;

void setup() {
  // Configure Output I/O pins
  PORTB = 0;
  DDRB = (1<<H_SYNC) | (1<<V_SYNC);

  // Run a timer interrupt off a 64 MHz clock
  PLLCSR |= (1<<PLLE);            // Enable 64 MHz PLL clock
  while (!(PLLCSR & (1<<PLOCK))); // Wait for the PLL lock
  PLLCSR |= (1<<PCKE);            // Enable PLL as source for Timer 1

  // Timer 1 for CTC mode and set on compare with OCR1A and overflow interrupt
  TCCR1 = (1<<CTC1) |                // Reset on match with OCR1C
          (1<<CS12) |                // Prescale /8
          (1<<PWM1A) |               // PWM mode
          (1<<COM1A1) | (1<<COM1A0); // Set OC1A on compare; clear on rest
  GTCCR = 0;
  OCR1A = 15;
  OCR1C = 218;  // Experimentation shows this is the best value

  // Enable Overflow Interrupt
  TIMSK = (1<<TOIE1);

  V_Sync_Line = 0;
}

void loop() {
  // put your main code here, to run repeatedly:
}

// Timer 1 Match with OCR1A interrupt
ISR (TIMER1_OVF_vect) {
   // Triggered every H_Sync line
   //
   // It automatically outputs the H_Sync pulse, so need to complete the line:
   // <---- H line Pixel output ---->
   //
   // From timings,  is approx 5.8 uS i.e. approx 23 ticks
   // So read the timer register and ensure it is > 23
   //
   while (TCNT1 < 24) {};

   if (V_Sync_Line <= 479) {
      // Visible line output
      // todo next!
    } else if (V_Sync_Line == 480) {
      // V Front Porch
    } else if ((V_Sync_Line >= 481) && (V_Sync_Line <= 483)) {
      // V Sync Pulse
     PORTB &= ~(1<<V_SYNC);
   } else { // 484 onwards
      // V Back Porch
     PORTB |= (1<<V_SYNC);
   }

   V_Sync_Line++;
   if (V_Sync_Line >= 500) {
     V_Sync_Line = 0;
   }
}

Permalink Leave a Comment

Arduino and the Minimus32

April 25, 2020 at 12:08 pm (maker, Uncategorized) (, , )

I’ve had some Minimus boards kicking around for, well, since 2012 or so but they kind of lost their interest as I acquired more Arduino-compatible boards of other varieties.  But an application has recently come up that I thought might fit the Minimus so I brushed the dust off my pair of Minimus 32 boards and thought I’d see what the Internet thought about them today.  It turns out not very much – most of the information I found was back around the same time I was originally trying them out.  Can you still buy these?  I’m not entirely sure!

One thing I did find though was some information on a board package for the Arduino IDE, so I had a go at getting it running on my current installation (1.8.12).  Turns out it isn’t too bad these days – as usual thanks to the hard work of others.  Here is what I needed to get it up and running.

Key links:

After adding the following line to my list of board definitions in the Arduino preferences, and restarting the IDE, I was able to search for “minimus” in the board manager and install the package:

At this point I now have a “minimus32” and “minimus16” option to select as a board.

In order to use the Arduino IDE to download and run code, you’ll need to install an Arduino compatible bootloader onto your Minimus 32.

I used an USBasp programmer with the following connections:Minimus 32 Arduino ISP Programming

There was a problem invoking AVRDude however using “burn bootloader” – I got the following error:

java.io.IOException: Cannot run program "{path}/bin/avrdude": CreateProcess error=2, The system cannot find the file specified

Which turned out to be a problem in the platform.txt file which for me could be found here:

  • [USER]AppData\Local\Arduino15\packages\minimus-arduino\hardware\avr\1.0.2\platform.txt

in the section “AVR Uploader/Programmers tools” the following line was required before the tools.avrdude.cnd.path and tools.avrdude.config.path lines:

tools.avrdude.path={runtime.tools.avrdude.path}

On restarting the IDE it was now possible to burn the boot loader successfully. At this point, the Minimus 32 was recognised as a COM port looking like an Arduino Leonardo.

Note that the pin-out for the Minimus 32 is slightly different from the original board – see the diagram from https://github.com/pbrook/minimus-arduino/wiki.

I’ll describe my project in a further post, but for now, many thanks, as always, to Paul Brooks and Kimio Kasaka for putting this stuff together.

Kevin

Permalink Leave a Comment

Programming a MiniMO Synth

April 19, 2020 at 12:03 pm (computers, maker, music, Uncategorized) (, , )

I’ve been playing with a home-grown version of the MiniMO synth as the creator has very kindly put the designs out into the public domain.

But a key issue with programming the ATtiny85 devices used in the synth is incompatibility with the latest versions of the Arduino IDE and the SpenceKonde ATTiny85 core that is now easily installed within it.

Warning: The official advice is still to build using Arduino 1.5.7, so treat all this as unverified and experimental.

I did have a look at this in the past and the issue seems to be one of incompatible timers, that I’ve described before.  The MinoMO uses both timers of the ATTiny85, but by default the core assumes the use of Timer 0 overflow interrupt for the delay/millis function, but several of the programmes for the MiniMO also want to use the overflow interrupt.

Expanding on the solution described in my previous post  – if we are assuming an 8-bit timer then it will overflow at 255, so setting the compare-on-match to 255 should have the same effect, but generate the TIMER0_COMPA_vect interrupt instead (at least for the mode being used here).

However, there is one caveat to all this.  The MiniMO synth code (I’m looking at the DCO code right now) sets the following parameters for Timer 0:

  //Timer Interrupt Generation -timer 0
  TCCR0A = (1 << WGM01) | (1 << WGM00); // fast PWM
  TCCR0B = (1 << CS00);                // no prescale
  TIMSK = (1 << TOIE0);                // Enable Interrupt on overflow

As far as I can see the original use of Timer 0 in the ATTiny Core is Fast PWM but with a prescalar value of 64.  Changing it to no prescale value here means that the “tick” used for the delay and millis functions is now running 64 times faster than previously assumed.

I’m guessing the author had the same issue in the original code though (although presumably with the settings for Timer 1), as in almost all other cases he uses the library function _delay_ms() rather than the Arduino function delay() or millis() – there is one exception – a couple of functions called on power-up prior to changing the timer values, which use the Arduino delay() function.

So from what I can see for the few programmes I’ve used with the MiniMO so far, I believe this is probably the only thing that needs changing if programming your own from the latest Arduino IDE and SpenceKonde ATTiny85 Core.  At least, on manual review of the code so far, I’ve not spotted any potential issues with having delay() and millis() running too fast!  But this isn’t an extensive review, and I repeat, the official advice is still to use an older version!

I don’t have an original MiniMO to compare waveforms to see if all the timing appears correct or not, but so far, I’ve been able to calibrate the frequency of the DCO (required as my ATTiny85 had no pre-set values stored in EEPROM), change waveforms, and see all three frequency ranges.

The fuse settings I used (as detailed by the menus in the SpenceKonde Core for ATTiny85 and then set using “burn bootloader”) were:

  • 8 MHz Internal
  • B.O.D disabled
  • EEPROM not retained (removes calibration data on re-programming)
  • Timer 1 Clock = CPU
  • LTO = Enabled
  • millis = Enabled

Which translates over into the following fuse settings:

  • efuse: 0xFF
  • hfuse: 0xDF
  • lfuse: 0xE2

I’d really like to know if anyone can compare the waveforms and frequencies generated by an original MinoMO DCO with one programmed with the above to see if they are the same.  Either way, for me I have a functioning unit, programmed using a current version of the Arduino IDE and ATTiny85 support and look forward to trying some of the other programmes for it too.

Of course, a massive thanks to Jose of course for putting the designs out there for experimentation like this in the first place.

Kevin

 

Permalink Leave a Comment