Baracuda + Micro

[Michaelo]

By default interrupts are not interruptable. The initial cli() and final sei() instructions in the ISR are unnecessary. It also means that delay() which interrupt-based cannot service its interrupts during the 310us taken by your ISR.

Appreciate that, it appears the processor does that for you... but you get the idea..

As I said above it not an ideal solution, even using multiple delayMicroseconds inside an interrupts has some issues...
I would have preferred to generate the pulses independently but apparently I would need a faster clock frequency...

I will probably change from using delayMicroseconds to using a counter/timer loop to achieve the same result later on...
Mike

[Michaelo]

Here's the code with the delayMicroseconds()

void do_isr()
{
  unsigned long now = 0;
  unsigned long then = 0;
 
  if (in_long_isr)
  {
    return;
  }
  in_long_isr = true;

  PINC = 0x01;
  for(int i = 0; i < TX_PULSE; i++)
  {
    __asm__("nop\n\tnop\n\tnop\n\tnop\n\tnop\n\t");
    __asm__("nop\n\tnop\n\tnop\n\tnop\n\tnop\n\t");
    __asm__("nop\n\tnop\n\tnop\n\t");
  }
  PINC = 0x01;
  for(int i = 0; i < PULSE_1_DELAY; i++)
  {
    __asm__("nop\n\tnop\n\tnop\n\tnop\n\tnop\n\t");
    __asm__("nop\n\tnop\n\tnop\n\tnop\n\tnop\n\t");
    __asm__("nop\n\tnop\n\tnop\n\t");
  }  
  PINC = 0x02;
  for(int i = 0; i < PULSE_1; i++)
  {
    __asm__("nop\n\tnop\n\tnop\n\tnop\n\tnop\n\t");
    __asm__("nop\n\tnop\n\tnop\n\tnop\n\tnop\n\t");
    __asm__("nop\n\tnop\n\t");
  }  
  PINC = 0x02;
  for(int i = 0; i < PULSE_1_DELAY; i++)
  {
    __asm__("nop\n\tnop\n\tnop\n\tnop\n\tnop\n\t");
    __asm__("nop\n\tnop\n\tnop\n\tnop\n\tnop\n\t");
    __asm__("nop\n\tnop\n\t");
  }  
  PINC = 0x04;
  for(int i = 0; i < PULSE_2; i++)
  {
    __asm__("nop\n\tnop\n\tnop\n\tnop\n\tnop\n\t");
    __asm__("nop\n\tnop\n\tnop\n\tnop\n\tnop\n\t");
    __asm__("nop\n\tnop\n\t");
  }  
  PINC = 0x04;   
  in_long_isr = false;
}

Works just like before....

TX pulse = 100.0uS
Sample Pulse 1 = 45.60us
Sample Pulse 2 = 45.60uS
Frequency = 641.0 Hz

[ODM]

One can also nest interrupts by enabling them after entering an interrupt. This can be done as far as stack remains for saving previous context.

Also, AVR has an interrupt ambiguity of 2 cycles as instructions run for 1-3 cycles. This makes for 100ns jitter at 20MHz, unless accounted for somehow such as sleeping cpu before timer interrupt or by reading timer value. This is probably of no matter for a run of the mill PI detector though!

[ODM]

it's extremely easy to connect A/D and D/A converters through I2C and SPI to attiny and atmega. I have done both

I2S is a different beast, though. Many 96/192kHz AD/DA for audio purposes use this type of interface and it is popular for audio DSP as well. https://en.wikipedia.org/wiki/I%C2%B2S

The good thing about I2S is the hardware is cheap and numerous and generally interfaces in a similar manner. The bad thing is its bit clock that can't be stopped even by the master, and AVR doesn't have dedicated hardware for catching bytes from a continuous stream in an elegant manner.

General AVR SPI can't load/read while transmission is in progress so actual bit rate will depend on SPI handling latency. UART in SPI mode is something I used for updating a two-byte DAC value by timer interrupt, which took less cycles than sending one complete byte did. It'll depend on the application if it's worth it or not, and one can always argue that a heavier mcu should be used instead.

STM32 will handle I2S rather nicely, though it's a space shuttle compared to PIC/AVR when actually digging into how the hardware works. I2S hardware might not be that applicable for PI detectors as there's often some bitstream filters and whatnot in the deltasigma type converters that cuts on the actual bandwidth, but 24-bit 192kHz on a few channels might be very welcome for VLF detectors.

[Davor]

Also, AVR has an interrupt ambiguity of 2 cycles as instructions run for 1-3 cycles. This makes for 100ns jitter at 20MHz, unless accounted for somehow such as sleeping cpu before timer interrupt or by reading timer value. This is probably of no matter for a run of the mill PI detector though!

This is a completely new moment for me. I was not aware of this. So in effect I can't rely on AVR to provide jitter-less digital output?

Say, if I want to clock a VLF coil with AVR, I may expect some FM noise as a consequence of jitter. And there is no way around it unless it is the only thing AVR does, which renders it to a mere CMOS divider. Bummer.

[Orbit]

Mnogo babica i tako dete osta bez imena . Ivice prevedi im ako zatraze hvala !

[ODM]

So in effect I can't rely on AVR to provide jitter-less digital output?

You can. It is only interrupt latency related. And like I wrote in the same post, that can be fixed by reading timer value and adding a few idle cycles, or sleeping the cpu before interrupt. This can be done in interrupt "before" interrupt for example. And timer hardware output pins have no latency related jitter of course.

Poorly regulated or ground noisy conditions, logic gate timers can have equal jitter or worse. So that shouldn't be an issue for performance equal to most "seasoned" PI designs that get so much love...

[Teleno]

Mnogo babica i tako dete osta bez imena.

Many grandmas and so the child was left without a name.

[Orbit]

Many grandmas and so the child was left without a name.

Thank you Teleno !

[Qiaozhi]

Mnogo babica i tako dete osta bez imena . Ivice prevedi im ako zatraze hvala !

Please make your posts in English, as per the forum rules.

[Michaelo]

One can also nest interrupts by enabling them after entering an interrupt. This can be done as far as stack remains for saving previous context.

Also, AVR has an interrupt ambiguity of 2 cycles as instructions run for 1-3 cycles. This makes for 100ns jitter at 20MHz, unless accounted for somehow such as sleeping cpu before timer interrupt or by reading timer value. This is probably of no matter for a run of the mill PI detector though!

The jitter you speak of, could it manifest in slight glitches on otherwise perfect pulses? I ask because while monitoring the pulse generated with different code samples, some exhibited very slight jitter and it was not extraneous noise or interference...

Mike

[Orbit]

Mr. Qiaozhi I know that you do programming help us little ! Otherwise translated Teleno !

[Davor]

You can. It is only interrupt latency related. And like I wrote in the same post, that can be fixed by reading timer value and adding a few idle cycles, or sleeping the cpu before interrupt. This can be done in interrupt "before" interrupt for example. And timer hardware output pins have no latency related jitter of course.

Poorly regulated or ground noisy conditions, logic gate timers can have equal jitter or worse. So that shouldn't be an issue for performance equal to most "seasoned" PI designs that get so much love...

OK, that makes a bit more sense. At first it seemed AVR lapses these clocks randomly, but if I make sure it gets equal treatment on every interrupt, the latency remains the same, and jitter-free. Thanks.

[ODM]

The source of that jitter is instruction length in cycles. An ongoing instruction is executed before interrupt is handled. Unless running random code the interrupt isn't random

"Otherwise perfect pulses" are perfect pulses clock by clock. Crystal osc jitter is negligible compared to skipping cycles. You need to look at the output code for your interrupt to pulse handler if you want to see the reasons. Any conditionally run code is going to add its own variable delay, so process it after updating outputs.

Lets say you have an overflow interrupt, as timer hits zero; first in the interrupt the ongoing instruction is processed and after that, a jump into interrupt vector (fixed code address) happens and the vector contains a jump to your interrupt routine. At the beginning of that routine, context (status register and work registers the interrupt uses) are pushed into stack, and we now see a fixed delay of cycles has passed for those pushes plus our ambiguous part (instruction in progress when interrupt triggered). We read the timer value, calculate number of no-operation instructions (NOP) we need, then relative jump into a few rows of NOP into the appropriate spot. Great, now we have jitter free code! Write outputs with previously generated values from last interrupt, generate or table-lookup new ones for next interrupt, and return.

Or we sleep the cpu in ovf before comp interrupt a few cycles later, and we are good.

But there is nothing magic about it, this is all in the complete datasheets. Nothing is going to spoil "perfect pulses" if the processor isn't told to do so

[Teleno]

Lets say you have an overflow interrupt, as timer hits zero; first in the interrupt the ongoing instruction is processed and after that, a jump into interrupt vector (fixed code address) happens and the vector contains a jump to your interrupt routine. At the beginning of that routine, context (status register and work registers the interrupt uses) are pushed into stack, and we now see a fixed delay of cycles has passed for those pushes plus our ambiguous part (instruction in progress when interrupt triggered). We read the timer value, calculate number of no-operation instructions (NOP) we need, then relative jump into a few rows of NOP into the appropriate spot. Great, now we have jitter free code! Write outputs with previously generated values from last interrupt, generate or table-lookup new ones for next interrupt, and return.

Or we sleep the cpu in ovf before comp interrupt a few cycles later, and we are good.

A PI does not need to be computation-intensive application. With a 1.000Hz scanning rate you got a full millisecond to produce the Tx pulses, the sampling pulses and massage the data. ISR aren't even necessary, a simple polling loop at the end of each cycle for testing the timer interrupt flag allows you to react immediately without the uncertainty of pending instructions and the stack overhead.