Posts with «debug» label

This Arduino Debugger Uses the CH552

One of the things missing from the “classic” Arduino experience is debugging. That’s a shame, too, because the chips used have that capability. However, the latest IDE has the ability to work with external debuggers and if you want to get started with a classic ATMega Arduino, [deqing] shows you how to get started with a cheap CH552 8-bit USB microcontroller board as the debugging dongle.

The CH552 board in question is a good choice, primarily because it is dirt cheap. There are design files on GitHub (and the firmware), but you could probably pull the same trick with any of the available CH552 breakout boards.

There was a time when having a god-eye view of your embedded system required an expensive in-circuit emulation system. These were expensive, difficult to deploy, and rare. Then, CPUs started adding debugging hardware right on the chip. A few spare pins on the CPU and some sort of adapter would give you most of what you wanted from an emulation system. Although these adapters are often proprietary, sometimes they aren’t, or they have been reverse-engineered. If you know the protocol, it is easy enough to get a processor to speak it for you. That’s why you often see, for example, Raspberry Pi Picos debugging other Picos. There’s nothing you can’t do a million other ways here, but it is an excellent step-by-step tutorial for getting started without breaking the bank.

Debugging with Serial Print at 5333333 Baud

Debugging with printf is something [StorePeter] has always found super handy, and as a result he’s always been interested in tweaking the process for improvements. This kind of debugging usually has microcontrollers sending messages over a serial port, but in embedded development there isn’t always a hardware UART, or it might already be in use. His preferred method of avoiding those problems is to use a USB to Serial adapter and bit-bang the serial on the microcontroller side. It was during this process that it occurred to [StorePeter] that there was a lot of streamlining he could be doing, and thanks to serial terminal programs that support arbitrary baud rates, he’s reliably sending debug messages over serial at 5.3 Mbit/sec, or 5333333 Baud. His code is available for download from his site, and works perfectly in the Arduino IDE.

The whole thing consists of some simple, easily ported code to implement a bare minimum bit-banged serial communication. This is output only, no feedback, and timing consists of just sending bits as quickly as the CPU can handle, leaving it up to the USB Serial adapter and rest of the world to handle whatever that speed turns out to be. On a 16 MHz AVR, transmitting one bit can be done in three instructions, which comes out to about 5333333 baud or roughly 5.3 Mbit/sec. Set a terminal program to 5333333 baud, and you can get a “Hello world” in about 20 microseconds compared to 1 millisecond at 115200 baud.

He’s got additional tips on using serial print debugging as a process, and he’s done a followup where he stress-tests the reliability of a 5.3 MBit/sec serial stream from an ATMega2560 at 16 MHz in his 3D printer, and found no missed packets. That certainly covers using printf as a debugger, so how about a method of using the debugger as printf?

Quasi real-time oscilloscope: REMIX

 Updated on 21 Sept. 2012, version 4.

 Updated on 15 Oct. 2012, version 5.

Recently I was reviewing one of my oldest project, and decided to “refresh” previous design by taking full advantage of the new arduino Leonardo board.  Based on AtMega32U4, which include PGA (programmable gain amplifier), oscilloscope’s  analog front end doesn’t require external OPA this time, end could be build in 1-2 hours on prototype board, using 5 resistors, 5 capacitors and one IC. Short specification:

  • Four channels.
  • Switchable gain settings 1x, 10x, 40x, 200x.

Hardware.

 As you can see on drawings above, inputs are AC coupled with caps, and biased with 1.25V generated by LM317. Connector for other two inputs not installed yet.

Software.

Project keeps almost same  structure of commands (CLI – command line interface) as its ancestor, with only two new for channel and gain selection. Read comments, it explains how to use them. One more things, I removed “r” – re-print option from the list of available commands.

Have fun!.

Link to arduino Leonardo sketch:  Oscilloscope_Leonardo.

********************************************* Version 4*********************************************

 Well, even posted above sketch has low complexity, and its good for beginning, nevertheless it’s quite limited as measuring device. The most important feature for oscilloscope, except V/div,  is T/div, or timing, that has to be as much precise as possible.   This is why “standard” timing options based on TIMER1 were add to next version of software. There are 9 time settings Time/div (10 samples):

50ms, 20ms, 10ms, 5ms, 2ms, 1ms, 500us, 200us, 100usec

corresponding to

200Hz, 500Hz, 1kHz, 2kHz, 5kHz, 10kHz, 20kHz, 50kHz, 100kHz

sampling rate. You can choose any of of this in the same manner, entering a digit 1-9 and letter d (display). Zero would skip capture, and just do whatever next letter request. Basically, 0 should be used to print channels data from memory. Combination: 9d0i – capture at 100 kHz rate, print chart and info-table,
4c2g7d – select 4-th channel, set gain to 10, select 20 kHz sampling rate and display.

I also add multichannel sampling capability. Commands 2m, 3m or 4m would configure oscilloscope for 2, 3 or 4 channels simultaneously capturing input waveform.   As arduino has only 1 ADC, switching in multichannel mode would reduce sampling rate proportionally to number of channels, and this changes would be reflected in right top corner of the display. What more, arduino would automatically change vertical resolution per channel, to fit all 2 – 4 charts on one screen!

Known caveats:

  • Sampling rate 9, or 100 usec per division (10 usec per sample) could not be selected in multichannel mode, should be in use for single channel only (1m, 1c – 2c – 3c – 4c).
  • There is a “shift” in channel number, signal  presented at input 1 would show up on screen 2, and so on. This happens on time settings 7 (occasionally), 8 and 9 in 4x multichannel mode due delay in MUX registers switching. Shouldn’t be an issue for 2x channel mode, or when you have an “overview” of the signals shape in single channel mode (1m) before switching to 4x, so you would know what to expect at each input port.

Link to arduino Leonardo sketch:  Oscilloscope_LeonardoV4

********************************************* Version 5*********************************************

 New updated version. I was thinking how to improve simplest ever oscilloscope, and have made some structural changes in the code, mostly related to sampling in multichannel mode.

First of all, instead of “delay” 2 microseconds, that was used to give a multiplexer (and PGA amplifier) time to “settle” on new channel, I decided not to waste a time (that may be priceless in real-time application), rather start new conversion, than track samples based on the “history” of MUX settings, and store new sample in corresponding two dimensional array box. Now MUX and PGA would have more time,  and consequently I could reduce ADC pre-selector’s clock to get better readings. It solved all the problems with wrong association port number and picture on the screen.

Secondly,  as you, probably, already notice I’ve been working on another project recently, where phase is a PRIME factor of the whole idea of the design. Phase noise is a jitter, and it degrades  spatial resolution and the sensitivity of the sound localization.  Jitter always would be presented in the incoming signal – sampled waveform due “not synchronous” way of sampling, as “start new conversion” events were generated in “manual” mode. As microprocessor spend different amount of time to get inside of the ISR (interrupt subroutine) depends on where it was interrupted, time frame of the events, basically, was not defined. In order to get rid off the phase noise, I changed ADC settings to be triggered via TIMER 1. There is a code:

ADCSRA = ((1<< ADEN)| // 1 = ADC Enable
(0<< ADSC)| // 1 = ADC Start Conversion
(1 <<ADATE) | / / 1 = ADC Auto Trigger Enable
*****
ADCSRB = ((1<<ADHSM)| // High Speed mode select
(0<< MUX5)| // 0 (10100) ADC1<->ADC4 Gain = 1x.
(0<<ADTS3)|
(1 <<ADTS2) | / / Sets Auto Trigger source Timer/Counter1 Compare Match B
(0 <<ADTS1) |
(1 <<ADTS0) );

For some unknown for me reason, Atmel designed TIMER 1 channel B to be an auto trigger source of the ADC, the same time to run TIMER 1 itself in CTC mode, channel A must be set. I simply “bind” two channels A and B in “parallel”, so both of them rise interrupt flag at the same moment, only A re-starts a TIMER 1, and B generates “start new conversion” event and calling ISR for “maintenance” – take a new sample waiting in the line and switch a MUX to another channel of the oscilloscope.

uint8_t take_it( int fast )
{
   ADCSRA &= 0xF8;
   if ( multChan -1 )
   {
    switch( fast ) { 
       case 7: // 20 kHz / 
         ADCSRA |= 0×03; 
         break; 
       case 8: // 50 kHz / 
         ADCSRA |= 0×02; 
         break; 
       case 9: // 100 kHz / 
         Serial.print(F(“\n\t *** NOT SUPPORTED ***”));
         return 0;
        default:
        ADCSRA |= 0×04;
       }
     }
    else
    { 
     switch( fast ) { 
        case 6: // 10 kHz / 
          ADCSRA |= 0×06; 
          break; 
        case 7: // 20 kHz / 
          ADCSRA |= 0×05; 
          break; 
        case 8: // 50 kHz / 
          ADCSRA |= 0×04; 
          break; 
        case 9: // 100 kHz / 
          ADCSRA |= 0×03; 
          break; 
        default:
          ADCSRA |= 0×07;
        }
      }
OCR1A   = smplTime[fast -1];
OCR1B   = smplTime[fast -1];
TCNT1   = 0;
TIFR1    |= (1<<OCF1B); 
TIMSK1 |= (1<<OCIE1B);
   flagSamp = 0; 
   while ( !flagSamp );
   for ( uint8_t indx, y = 0; y < multChan; y++){
      if ( multChan -1) indx = y;
      else indx = chanNumb;
   for ( int i = 0; i < INBUF; i++){
      if ( x[indx][i] & 0×0200) x[indx][i] += 0xFE00; // Convert to negative 16-bit word (2′s comp)
      else x[indx][i] += 0×200;
      }
     }
  return 1;
}
ISR(TIMER1_COMPB_vect)
{
   static uint8_t n_sampl = 0;
   static uint8_t history = 0;
   x[history][n_sampl] = ADC;
    history = chanNumb; 
   if ( multChan -1 )
   { 
    chanNumb++;
    if ( chanNumb >= multChan )
      {
       chanNumb = 0;
       n_sampl++;
      }   
     ADMUX &= 0xFC;
     ADMUX |= chanNumb; 
    }
   else
   {
     n_sampl++;
    }
   if ( n_sampl >= INBUF )
    {
      flagSamp = 1;
      n_sampl = 0;
TIMSK1 &= ~(1<<OCIE1B);
   }
}

Oscilloscope_Leonardo_V5.

The only issue that not solved yet, is a sampling in multichannel mode in “9″ T/div. Probably, Atmel just was not design to do such things…