Composite video only needs the 75 ohm load resistor if the input to the TV is high impedance. Almost all TVs have a 75 ohm input impedance already so the load resistor isn't needed - the TV is the load

According to the data sheet there is a slight output resistance on the digital outs, you may find 82 ohm resistors work better than 68. Try it, it will either look better or worse. I did write a sketch to test how monotonic the DAC is - put a 75 ohm load resistor in place for this (doesn't have to be exactly 75 ohms) and connect the output to analog in 0:

Code:

// array runs lsb to msb, you can add/remove
// values according to the number of resistors
// in your DAC
char pins[]={34,35,36,37,38,39,40,41};

void writeval(int v){
  for(int i=0;i<sizeof(pins);i++){
    digitalWrite(pins[i],v&1);
    v>>=1;
  }
}

void setup() {
  Serial.begin(115200);
  analogReadResolution(12);
  for(int i=0;i<sizeof(pins);i++)
    pinMode(pins[i],OUTPUT);
}

void loop() {
  int l=0;
  for(int i=0;i<(1<<(sizeof(pins)));i++){
    writeval(i);
    delay(10);
    int m=analogRead(0);
    printf("%d : %d  d=%d\n",i,m,m-l);
    if(m<l)printf("!!!!!!ERROR!!!!!!!!!! non-monotonic\n");
    l=m;
  }
  delay(2000);
}

Because of the number of technical compromises that have to be made to get a colour composite signal at all, there will always be a lot of colour fringe. The output signal is way off spec in a number of areas. I aimed low with that project, the goal was VHS quality rather than broadcast quality

Thanks for testing it, I have given it many hours of testing myself too and have had no errors. I've opened a pull request on github: https://github.com/arduino/Arduino/pull/1388

Try isfinite, isinf or possibly isnan
 http://www.nongnu.org/avr-libc/user-manual/group__avr__math.html#ga18a7409e0b2341afaa41993960961772

eg. Serial.print(isfinite(f)?f:0);

This fix appears to be better than I first thought I have now given it a couple of hours testing without error.

This is my current version of the fix, it adds some optimizations for speed. It probably isn't as fast as it could be (a call takes about 1.8us).
hardware/arduino/sam/cores/arduino/wiring.c :

Code:

uint32_t micros( void )
{
    uint32_t ticks, ticks2;
    uint32_t pend, pend2;
    uint32_t count, count2;

    ticks2  = SysTick->VAL;
    pend2   = !!((SCB->ICSR & SCB_ICSR_PENDSTSET_Msk)||((SCB->SHCSR & SCB_SHCSR_SYSTICKACT_Msk)))  ;
    count2  = GetTickCount();

    do {
        ticks=ticks2;
        pend=pend2; 
        count=count2;
        ticks2  = SysTick->VAL;
        pend2   = !!((SCB->ICSR & SCB_ICSR_PENDSTSET_Msk)||((SCB->SHCSR & SCB_SHCSR_SYSTICKACT_Msk)))  ;
        count2  = GetTickCount();
    } while ((pend != pend2) || (count != count2) || (ticks < ticks2));

    return ((count+pend) * 1000) + (((SysTick->LOAD  - ticks)*(1048576/(F_CPU/1000000)))>>20) ;
}

Thanks for the detailed test case, it really helps a lot - I meant to look at this particular bug a couple of months ago when others noticed it but didn't because there wasn't full code to reproduce the bug. Nevertheless it's still taken hours of hard work and I haven't completely fixed it, although I think I've improved things.

Basically there is a very complicated race condition going on. There are SysTick interrups every millisecond which micros() uses to calculate the thousands of microseconds in the result, and also your pin change interrupt. Bad things can happen if the SysTick interrupt triggers while you are in the middle of the pin change - it has to wait for your interrupt to finish before it can update the millis counter which messes up the timing.

Please try the following: In hardware/arduino/sam/cores/arduino/wiring.c change the function micros() to this:

Code:

uint32_t micros( void )
{
volatile    uint32_t ticks, ticks2;
volatile        uint32_t pend, pend2;
volatile     uint32_t count, count2;

        ticks2  = SysTick->VAL & 0xffffff;
        pend2   = ((SCB->ICSR & SCB_ICSR_PENDSTSET_Msk)||((SCB->SHCSR & SCB_SHCSR_SYSTICKACT_Msk)))  ? 1 : 0;
        count2  = GetTickCount();

do {
        ticks=ticks2;
        pend=pend2;
        count=count2;
        ticks2  = SysTick->VAL & 0xffffff;
        pend2   = ((SCB->ICSR & SCB_ICSR_PENDSTSET_Msk)||((SCB->SHCSR & SCB_SHCSR_SYSTICKACT_Msk)))  ? 1 : 0;
        count2  = GetTickCount();
} while ((pend != pend2) || (count != count2) || (ticks < ticks2));

    volatile uint32_t r=((count+pend) * 1000) + ((84000  - ticks) / 84) ;

        return r;
}

It is complicated to describe but what it does is repeatedly read the timer values and detects pending timer ticks until it thinks it has sensible readings, then it calculates micros from those. I tried it on your code for 5 minutes and it was OK and I've tested it for monotonicity for 5 minutes too, but there's so much code out there that uses micros() I can't guarantee it works on everything.

Serial3 works fine here.

Please do post the host side code. In particular, have you set the port to raw mode? It may be cooking your data hence losing bytes. Try "stty -F /dev/ttyACM0 sane raw" before running your code (look at the stty manpage for other options)

Yes you could use that although it is actually 6 bit, not 8, so in colour mode you would only get 64 colours (you might be able to get all 256 by adding a few extra resistors). Mono mode should be just fine. It would need a bit of work to wire it to the right pins - it wouldn't just be able to plug straight into the Due like it can with a Papilio.

Basically yes, the shimmering problem was caused by the interrupt not firing with exactly the same period each time, so each line is a random number of ticks late. What the mysterious piece of inline assembler at the start of the interrupt is trying to do is to synchronize the CPU with the timer. But it is not a good solution.

In the VGA library I tried a different solution. It uses two interrupts each line - the first puts the processor to sleep, so then when the second one fires it should be precisely on time. The display is much more steady (in most cases, rock steady). This broke the Serial support, but in the last few days I think I have made a breakthrough and got it working again. The other advantage to the VGA library is that it now uses DMA for the colour mode which is about 4x faster since the processor can continue to execute code while the screen is being displayed, plus the pixels are all the same width

Unfortunately I don't have standalone code of this approach as I had already turned the code into a library by then.

Quick preview of the next release: Only minor bugfixes in the library, although one of those bugs was causing a hang when receiving Serial data, so if you use Serial and VGA you should upgrade (the fix is already in github master if you need it now)

The major addition is a new demo, which decodes GPS GPGGA/GPGSV strings and shows a rotated globe and satellite positions. Data can be taken from a real GPS or entered in the serial monitor. You have probably seen smartphone apps which do this, well now you can do it on an Arduino too Watch satellites move across the sky in real time (although only if you are very patient as it takes the satellites 6 hours to get from one side of their orbit to the other!)

I just realised where you went wrong:

int sampleSize = 1000000;

On a Uno int is 16 bits, so this will actually set sampleSize to 16960 

This can't be right,1 million digitalWriteFast pairs in 8ms on a Uno is an output frequency of 125MHz which is clearly way beyond the specification of the chip!

Thanks guys for this mission. I got 1 MHz working on the DUE, but I found that digitalWrite is slow. So it messes up my tc_handler. Doesn't leave it anymore. And I need to write in the ISR, maximum control every microsecond. You have a fast alternative for digitalWrite ?

digitalWriteDirect() will work faster than 1MHz, although it may be a challenge to get it that fast in an interrupt due to overhead. Try it anyway.

Code:

inline void digitalWriteDirect(int pin, boolean val){
  if(val) g_APinDescription[pin].pPort -> PIO_SODR = g_APinDescription[pin].ulPin;
  else    g_APinDescription[pin].pPort -> PIO_CODR = g_APinDescription[pin].ulPin;
}

inline int digitalReadDirect(int pin){
  return !!(g_APinDescription[pin].pPort -> PIO_PDSR & g_APinDescription[pin].ulPin);
}

Only platform.txt needs to be changed, as per cmaglie's post.

Just to reiterate what I said before - I've now had this modification for 2 months and have used the IDE heavily and have had absolutely no problems or incompatibilities at all with sketches not using the library. I would recommend this change to be included in the next IDE release.

Your condensers got condensed!