Hi,

Please switch the tool bar from Debug to Release and then upload.

You should then see visual micro working the same as the arduino ide.

Let's keep it simple and prove if that is the case or not before looking at debug which arduino does not support.

Thanks


note: To upload files it is best to zip them first or email them to info[at]visualmicro.com along with a link to this post.

Hi,

I don't think this is related to a visual micro installation issue. 

I am unclear from your report of a few things.

1)
In release mode can you compile and upload?

2)
With Release mode enabled, it would be helpful if you could restate your report of the issue. Please also state the comparison/difference between arduino ide and visual micro with exact same code.


Thanks

I think the problem is you have not specified a line terminator for serial sent from pc to mcu.

Your code reads looking for line feed as terminator.

If you right click and GoTo definition on the arduino readBytesUntil() method you will see it uses a time out for the read of 1 second. See code extract below.

Both your code and arduino read one byte at a time so maybe the ide > serial monitor > line terminator isn't sending the \n your code expects? 

What is No 8 set to in the Serial Monitor?



arduino stream.cpp

int Stream::timedRead()
{
  int c;
  _startMillis = millis();
  do {
    c = read();
    if (c >= 0) return c;
  } while(millis() - _startMillis < _timeout);
  return -1;     // -1 indicates timeout
} 

arduino stream.h defines _timeout

class Stream : public Print
{
  protected:
    unsigned long _timeout;      // number of milliseconds to wait for the next char before aborting timed read
    unsigned long _startMillis;  // used for timeout measurement
    int timedRead();    // private method to read stream with timeout
    int timedPeek();    // private method to peek stream with timeout
    int peekNextDigit(LookaheadMode lookahead, bool detectDecimal); // returns the next numeric digit in the stream or -1 if timeout

  public:
    virtual int available() = 0;
    virtual int read() = 0;
    virtual int peek() = 0;
    virtual void flush() = 0;

    Stream() {_timeout=1000;}
 

Thanks, you are right there are so many options these days that it needs to be clearer. It defaults to "No Line Endings" because that is what the Arduino Ide does (or used to do). I will test sometime to see if they have changed the default.

For debug you need to switch on "vMicro>Debugger>Trace Only" which will give you non-stopping read only trace points.

The docs try to explain that arduino does not have a debugger so Visual Micro provides a simple debugger with Serial. This message and the importance of it can be lost in the depths of the docs so it will help.

For debug to be able to break/pause/continue (and update variables) during run time visual micro needs exclusive use of the serial.read and serial.available() systems. 

When sharing the port with the debugger, your code can use serial.println etc but can not read.

You can override the serial port that visual micro uses for debugging. 

If you have more than one Serial port you can assign a different port to the debugger... For example "vMicro>Debugger>Remote Port" = Serial2 and "vMicro>Debugger>Local Port" = COMx

If you do not have a different hardware port but have one or two available digital pins you can set the debugger to use SoftwareSerial. One pin for Trace only and two pins for trace/break

Debugging-With-Different-Ports.html

In summary, for a clean debug experience that keeps serial usage separate between your own code and the debugger you will need something like an FTDI adapter or cable so that you have a second usb connection to the board via pins on the board.

Thanks for the update. Yes that's right... 

Because the serial debug code has to be injected into the temp code copy during build it was easier to insert after the current line. if that a single line "if" it's handled and turned into mult-line. 

It tries it's best to insert code but the simpler the code line the easier. Unlike normal debugger breakpoints on blank lines work and can sometimes be useful but it's certainly different

The Debugging Your Sketch topic  in the documentation index is a useful doc. See the section called "The Exact Location of a Breakpoint"