Baracuda + Micro

[ODM]

The improvements of adding a microcontroller would be very easy playing around with different drive pulse shapes and sampling schemes. Adding a coarse ground cancel scheme based on tx width and sample points (like the basis of MPS patent and others) would be a breeze to do in software compared to hardware. In this way I think the most humble barracuda/surf/etc '80s PI with resistor damping, preamplifier and sampling integrator would benefit from software control and "rocksolid" crystal bound timing while retaining that simplicity.

Though I would advise against easily replacing the integrator gain stage with AVR ADC. Particularly I'd be wary of using the AVR internal ADC amplifier for anything fast and precise - their own datasheets advise that one will get lower effective bits and recommend lower sampling speed with ADC. Also for the full 10 bits in AVR it really needs to run on a buffered reference that isn't the same rail as supply voltage (at least the internal bandgap with a polystyrene cap at AREF pin) with recommended ADC full range clock speed (rather low) and sleep the rest of that microcontroller during conversion. This is all recommended in their appnotes and various datasheets. XMEGA ADCs might be a pinch better but they are a minefield when it comes to using any of their gain/differential features, errata is rife with examples of what doesn't work, and those are only the officially recognized faults... That said, pretty much all microcontroller internal ADCs are crock, especially when comparing to dedicated ADCs in the same price range. They're good for saving PCB real estate and expense at the cost of performance, and for kitchen appliance use

Another thing that is not readily apparent is using a lossy integrator to enable oversampling, and by that route "fish out" the best that internal ADC can offer. Also, if there is already an integrator onboard, it could well be the basis of a software-operated integrating or sigma-delta ADC. Integrating ADCs are rather common in cheap multimeters for ease of construction, and expensive multimeters where the ADC is designed, built and used for precision.

[Michaelo]

Several well made points... I think I'll quote you first paragraph if anyone derides my building a bara with micro controlled timing again

Mike

[ivconic]

The test code is nothing more than a function call within the main loop.. it's really that simple...
It started life as a timer interrupt drive procedure but I ran into issues so I coded a simple pulse function (see below)...

I monitor the loop timing and adjust to achieve the correct duty cycle, this give me about 1.3mS to perform all the other tasks between cycles...
It's fine for pulses with some time for user adjustments via LCD but not ideal for continued development...

The code is not complete... it will not compile...

#define TX_PULSE         100 //(100uS) TX Pulse width of 100uS
#define PULSE_1_DELAY     10 //( 20uS) Delay before Main Sample Pulse 10-60uS
#define PULSE_1           45 //( 45uS) Sample 1 Pulse Duration 45uS
#define PULSE_2_DELAY     90 //( 90uS) Delay between Pulse 1 and Pulse 2 90uS (increase this!)
#define PULSE_2           45 //( 45uS) Sample 2 Pulse Duration 45uS
#define WAIT_PERIOD     1300 //(1.3ms) delay till next sequence
#define BCT 3600
#define BAT_LOW 1.50
#define CONTRAST_PIN       9 //15

int bcount = 0;
unsigned int duty_count = 0;
unsigned long loop_timer_start = 0;
unsigned long loop_timer_end = 0;
int adjust = 0;
int contrast = 65;
int xcol = 3;
int xrow = 2;
char key;
char menu_line_1a[]  = "       Menu      [A]";
char menu_line_1b[]  = "     Contrast    (D)";
char menu_line_1c[]  = "   Timing Menu   (B)";
char menu_line_1d[]  = "    Exit Menu    (*)";
int clean = 0;
int repaint = 0;

byte con[8] = {
  0b00100,
  0b01110,
  0b11111,  
  0b00000,  
  0b00000,  
  0b11111,
  0b01110,
  0b00100
};

LiquidCrystal lcd(8,7,6,5,4,3);

void setup ()
{
  pinMode (A0, OUTPUT);
  pinMode (A1, OUTPUT);  
  pinMode (A2, OUTPUT);
  pinMode (A5, INPUT);  
  digitalWrite (A0, LOW);
  digitalWrite (A1, LOW);
  digitalWrite (A2, LOW);

  pinMode(CONTRAST_PIN, OUTPUT);
  analogWrite (CONTRAST_PIN, contrast);
  lcd.createChar(1, con);
  lcd.begin(20, 4);
  lcd.setCursor(0, 0);
  delay(500);
  lcdstart();
  Serial.begin(9600);
}

void loop ()
{
  if(bcount++ > BCT) check_battery();
  
  pulses();

  duty_count++;
  
  if(duty_count == 1) loop_timer_start = micros();
  
  // control pulses per second //
  if(duty_count == 625)
  {
    duty_count = 0;    
  }
  
  if(duty_count == 1) loop_timer_end = micros();

  adjust = loop_timer_end - loop_timer_start;

  delayMicroseconds (WAIT_PERIOD - adjust);
}

void pulses ()
{
  cli () ;
  PINC = 0x01;
  delayMicroseconds(TX_PULSE);
  PINC = 0x01;
  delayMicroseconds(PULSE_1_DELAY);
  PINC = 0x02;
  delayMicroseconds(PULSE_1) ;
  PINC = 0x02;
  delayMicroseconds(PULSE_2_DELAY);
  PINC = 0x04;
  delayMicroseconds(PULSE_2);
  PINC = 0x04;
  sei () ;
}

With the present code it's probably not worth adding a Micro, even though you do have the option to control duty cycle, pulse durations and delays. It's more suited to experimentation...

The final code (assuming I can solve a current issue), should be a perfect place to begin expanding on...

Mike

Thanks.
Menu adjustments should be done in "off time" provided by hardware interrupt (key stroke for example).
But main "collision" would be between LCD displaying/updating variables and main loop.
Real time LCD updating variables; while at the same time running critical PI timing loop : is PROBLEM.
However it could be done, proof is FelezJoo PI.
I will follow your work with great attention.
Thanks in advance for your efforts.
Regards!

[ivconic]

Like this it will compile;

[Davor]

It should be worth your while studying microsecond timers, cli () and sei () manipulation of interrupts, as well as the way cli () stops millisecond timer

[Teleno]

It should be worth your while studying microsecond timers, cli () and sei () manipulation of interrupts, as well as the way cli () stops millisecond timer

cli() renders the milisecond timer useless. In the case of delayMicroseconds() there's no problem because it's a simple waiting loop, not interrupt based.

/* Delay for the given number of microseconds.  Assumes a 8 or 16 MHz clock. */
void delayMicroseconds(unsigned int us)
{
    // calling avrlib's delay_us() function with low values (e.g. 1 or
    // 2 microseconds) gives delays longer than desired.
    //delay_us(us);
#if F_CPU >= 20000000L
    // for the 20 MHz clock on rare Arduino boards

    // for a one-microsecond delay, simply wait 2 cycle and return. The overhead
    // of the function call yields a delay of exactly a one microsecond.
    __asm__ __volatile__ (
        "nop" "\n\t"
        "nop"); //just waiting 2 cycle
    if (--us == 0)
        return;

    // the following loop takes a 1/5 of a microsecond (4 cycles)
    // per iteration, so execute it five times for each microsecond of
    // delay requested.
    us = (us<<2) + us; // x5 us

    // account for the time taken in the preceeding commands.
    us -= 2;

#elif F_CPU >= 16000000L
    // for the 16 MHz clock on most Arduino boards

    // for a one-microsecond delay, simply return.  the overhead
    // of the function call yields a delay of approximately 1 1/8 us.
    if (--us == 0)
        return;

    // the following loop takes a quarter of a microsecond (4 cycles)
    // per iteration, so execute it four times for each microsecond of
    // delay requested.
    us <<= 2;

    // account for the time taken in the preceeding commands.
    us -= 2;
#else
    // for the 8 MHz internal clock on the ATmega168

    // for a one- or two-microsecond delay, simply return.  the overhead of
    // the function calls takes more than two microseconds.  can't just
    // subtract two, since us is unsigned; we'd overflow.
    if (--us == 0)
        return;
    if (--us == 0)
        return;

    // the following loop takes half of a microsecond (4 cycles)
    // per iteration, so execute it twice for each microsecond of
    // delay requested.
    us <<= 1;
    
    // partially compensate for the time taken by the preceeding commands.
    // we can't subtract any more than this or we'd overflow w/ small delays.
    us--;
#endif

    // busy wait
    __asm__ __volatile__ (
        "1: sbiw %0,1" "\n\t" // 2 cycles
        "brne 1b" : "=w" (us) : "0" (us) // 2 cycles
    );
}

[Teleno]

Though I would advise against easily replacing the integrator gain stage with AVR ADC. Particularly I'd be wary of using the AVR internal ADC amplifier for anything fast and precise -

Frist of all clarify that the Atmega328 has no ADC amplifier. The ATtiny family has a 20x analog amplifier in differential mode. The maximum ADC clock is 200KHz. Sample and Hold takes 1.5 ADC clock cycles, that is 7.5 us which seems too long.

A better alternative is the inexpensive MCP3201 with 12 bit resolution and a sampling clock at 1.6 MHz (5V). Sample and Hold also takes 1.5 ADC clock cycles which in this case is just a mere microsencond.

With the right ADC it's advantageous to replace the integrators by more versatile software algorithms (moving average, digital filters, etc.)

[Michaelo]

Just to note the complete code compiles perfectly... I've been using it for several days without a hiccup... I only post a section of it for discussion...
Post ivconic's post above (#34) contains a sketch that will compile...

@ivconic
User input and real time updating of the LCD can be scheduled, that is, the at the end of the pulse function we call a house keeping function to perform remaining tasks. The house keeping function monitors the time and if required it can save current conditions to a software stack and exit... On the next call, it resumes where it left off... That should be enough to facilitate close to real time give or take ~300uS...

I am forced to look for alternatives as the timer interrupt I was hoping to use is proving difficult. At best it looks like the code will need to be written in assembly but even so, at 16Mhz, you only have 16 instructions per 1uS... not a lot of time... No doubt it can be done but it's a very long time since I wrote an ISR so this is effectively all new to me. And to those who believe they may have found issues, try to be courteous in your response, don't just post sarcastic remarks...

I would still prefer to use a timer interrupt but I believe I can make the current code work as is, Having said that, if anyone can offer suggestion as regards timer driven interrupts and how I might over come the time limited or can point me in the direction of existing opensource code that already solves the problem I would be grateful...

Mike

[ODM]

No problem! I was just going by this

Reduce the gain of U1 by a factor of 20, set the internal OpAmp of the ATmega to a gain of x20.

The internal gain and differential modes are working (depending on silicon revision) solutions in later tiny/mega devices for a lot of interfacing things but for dynamic range they generally suck.

One thing to look at is interfacing with the ADC; there's no way to elegantly connect an I2S audio AD/DA device with the tiny/mega devices at least though there's usually some quirks to using them like DC accuracy and internal filtering from the sigmadelta process etc.

There's also no way to buffer SPI reads and writes with the hardware SPI port, unless using xmega and its pseudo-DMA options. One way around it with the atmega series is using UART serial port in SPI mode which allows using that port's buffer for SPI transfers.

[ivconic]

Just to note the complete code compiles perfectly... I've been using it for several days without a hiccup... I only post a section of it for discussion...
Post ivconic's post above (#34) contains a sketch that will compile...

@ivconic
User input and real time updating of the LCD can be scheduled, that is, the at the end of the pulse function we call a house keeping function to perform remaining tasks. The house keeping function monitors the time and if required it can save current conditions to a software stack and exit... On the next call, it resumes where it left off... That should be enough to facilitate close to real time give or take ~300uS...

I am forced to look for alternatives as the timer interrupt I was hoping to use is proving difficult. At best it looks like the code will need to be written in assembly but even so, at 16Mhz, you only have 16 instructions per 1uS... not a lot of time... No doubt it can be done but it's a very long time since I wrote an ISR so this is effectively all new to me. And to those who believe they may have found issues, try to be courteous in your response, don't just post sarcastic remarks...

I would still prefer to use a timer interrupt but I believe I can make the current code work as is, Having said that, if anyone can offer suggestion as regards timer driven interrupts and how I might over come the time limited or can point me in the direction of existing opensource code that already solves the problem I would be grateful...

Mike

As for the real time data update on LCD (bar scale, VDI number etc...) your solution looks as only possible and most logical. And that's the hardest part (for me and my level of knowledge).
As for the user adjustments through the menu(s); like i said: most elegant solution is to use hardware interrupt (invoked by key stroke). And that's the easiest part.
Because interrupt "freezes" all the processes and all the previous "math" stays correct. Only need small attention on fet, it must be set closed during the interrupt.

"...I am forced to look for alternatives as the timer interrupt I was hoping to use is proving difficult..."

Yes, that's where i am struggling.
I am trying to learn and master that.
But so far we don't have practical example of how is done.
Would be indeed good if we had FelezJoo source to learn from it.

[Teleno]

One thing to look at is interfacing with the ADC; there's no way to elegantly connect an I2S audio AD/DA device with the tiny/mega devices at least though there's usually some quirks to using them like DC accuracy and internal filtering from the sigmadelta process etc.

There's also no way to buffer SPI reads and writes with the hardware SPI port, unless using xmega and its pseudo-DMA options. One way around it with the atmega series is using UART serial port in SPI mode which allows using that port's buffer for SPI transfers.

Actually it's extremely easy to connect A/D and D/A converters through I2C and SPI to attiny and atmega. I have done both and there are libraries available. Buffering is not necessary for a PI application with 2-4 samples every millisecond.

[Teleno]

User input and real time updating of the LCD can be scheduled, that is, the at the end of the pulse function we call a house keeping function to perform remaining tasks. The house keeping function monitors the time and if required it can save current conditions to a software stack and exit... On the next call, it resumes where it left off... That should be enough to facilitate close to real time give or take ~300uS...

I am forced to look for alternatives as the timer interrupt I was hoping to use is proving difficult. At best it looks like the code will need to be written in assembly but even so, at 16Mhz, you only have 16 instructions per 1uS... not a lot of time... No doubt it can be done but it's a very long time since I wrote an ISR so this is effectively all new to me. And to those who believe they may have found issues, try to be courteous in your response, don't just post sarcastic remarks...

I would still prefer to use a timer interrupt but I believe I can make the current code work as is, Having said that, if anyone can offer suggestion as regards timer driven interrupts and how I might over come the time limited or can point me in the direction of existing opensource code that already solves the problem I would be grateful...

Mike

A PI cycle (Tx pulse, sampling, EF sampling) takes about 1ms. That's 1000 cycles per second. Every 50 or 100 PI cycles you skip one and dedicate the whole millisecond to refreshing the LCD display. You don't really need to refresh at 1000Hz.

[Michaelo]

I solved the interrupt issue but not exactly as I would have liked but this way it's a great deal easier. I simply move the pulse code inside the new timer ISR...

You can see the timing I'm using in the defines at the top of the code... some may need tweaking...

Test!!! Code!!!

#include <TimerOne.h>

#define CYCLE_TIME 1662 // 0.0015625 Seconds @ 640 PPS // added 100 to 1562 to make is closer to 640pps //

#define TX_PULSE         100 //(100µs)        100µs
#define PULSE_1_DELAY     20 //( 20µs)        Delay before Sample Pulse 1
#define PULSE_1           45 //( 45µs)        Sample 1 Pulse Duration
#define PULSE_2_DELAY    100 //( 100µs)        Delay between Sample Pulse 1 and Pulse 2
#define PULSE_2           45 //( 45µs)        Sample 2 Pulse Duration 45µs
/*
 Total Pulses Time        310
 -----------------------------
 Cycle Time              1562
 Pulse Times             -310
 Delay till next cycle   1252

 Actual cycle time is 1/1562 µs = ~640
*/

volatile bool in_long_isr = false;              // True if in long interrupt

int cnt = 0;
void setup()
{
  pinMode (A0, OUTPUT);
  pinMode (A1, OUTPUT);  
  pinMode (A2, OUTPUT);

  digitalWrite (A0, LOW);
  digitalWrite (A1, LOW);
  digitalWrite (A2, LOW);  
  
  Serial.begin(9600);

  Timer1.initialize(CYCLE_TIME);
  Timer1.attachInterrupt(do_isr);
}

void loop()
{
  Serial.println(cnt++);
  delay(100);
}

void do_isr()
{
  if (in_long_isr)
  {
    return;
  }
  in_long_isr = true;
  cli () ;
  PINC = 0x01;
  delayMicroseconds(TX_PULSE);
  PINC = 0x01;
  delayMicroseconds(PULSE_1_DELAY);
  PINC = 0x02;
  delayMicroseconds(PULSE_1) ;
  PINC = 0x02;
  delayMicroseconds(PULSE_2_DELAY);
  PINC = 0x04;
  delayMicroseconds(PULSE_2);
  PINC = 0x04;   
  sei () ;
  in_long_isr = false;
}

Generally speaking ISR should complete quickly but as we are only generating one interrupt this code seems perfectly reasonable...

You may note I'm using the analogue pins, that's because I've used all of the others for the Keys and LCD...
As usual, if you find any error please be polite when posting...

I've tested and scoped the pulses and everything look good, next to get the keys and LCD up and running...
Mike

[6666]

Test!!! Code!!!

What are you compiling it in ?

[Teleno]

I solved the interrupt issue but not exactly as I would have liked but this way it's a great deal easier. I simply move the pulse code inside the new timer ISR...

You can see the timing I'm using in the defines at the top of the code... some may need tweaking...

Test!!! Code!!!

#include <TimerOne.h>

#define CYCLE_TIME 1662 // 0.0015625 Seconds @ 640 PPS // added 100 to 1562 to make is closer to 640pps //

#define TX_PULSE         100 //(100µs)        100µs
#define PULSE_1_DELAY     20 //( 20µs)        Delay before Sample Pulse 1
#define PULSE_1           45 //( 45µs)        Sample 1 Pulse Duration
#define PULSE_2_DELAY    100 //( 100µs)        Delay between Sample Pulse 1 and Pulse 2
#define PULSE_2           45 //( 45µs)        Sample 2 Pulse Duration 45µs
/*
 Total Pulses Time        310
 -----------------------------
 Cycle Time              1562
 Pulse Times             -310
 Delay till next cycle   1252

 Actual cycle time is 1/1562 µs = ~640
*/

volatile bool in_long_isr = false;              // True if in long interrupt

int cnt = 0;
void setup()
{
  pinMode (A0, OUTPUT);
  pinMode (A1, OUTPUT);  
  pinMode (A2, OUTPUT);

  digitalWrite (A0, LOW);
  digitalWrite (A1, LOW);
  digitalWrite (A2, LOW);  
  
  Serial.begin(9600);

  Timer1.initialize(CYCLE_TIME);
  Timer1.attachInterrupt(do_isr);
}

void loop()
{
  Serial.println(cnt++);
  delay(100);
}

void do_isr()
{
  if (in_long_isr)
  {
    return;
  }
  in_long_isr = true;
  cli () ;
  PINC = 0x01;
  delayMicroseconds(TX_PULSE);
  PINC = 0x01;
  delayMicroseconds(PULSE_1_DELAY);
  PINC = 0x02;
  delayMicroseconds(PULSE_1) ;
  PINC = 0x02;
  delayMicroseconds(PULSE_2_DELAY);
  PINC = 0x04;
  delayMicroseconds(PULSE_2);
  PINC = 0x04;   
  sei () ;
  in_long_isr = false;
}

Generally speaking ISR should complete quickly but as we are only generating one interrupt this code seems perfectly reasonable...

You may note I'm using the analogue pins, that's because I've used all of the others for the Keys and LCD...
As usual, if you find any error please be polite when posting...

I've tested and scoped the pulses and everything look good, next to get the keys and LCD up and running...
Mike

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.