Pages: [1]   Go Down
Author Topic: Arduino micro and serial monitor  (Read 612 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
God Member
*****
Karma: 1
Posts: 547
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I have a 2 axis control routine that I  use to manipulate my micro mill. The application runs and communicates when hosted on an Arduino UNO, but fails to establish connection to the IDE's serial monitor when hosted on the new Arduino Micro. The Micro (32u4)  has its own USB functionality whereas the 328P on the UNO does not and relies on a 16u4 as a USB client. The serial routines are from the code examples in the reference section as shown below.
Code:
void loop()
{
    if(IsBusy == false)
      {
                ProcessInput();
      }
    else
    {
    if(CodeChangedVerb == true)
    {
    ThisOperation.Verb = RedirectVerb;
    ExecuteMovement();
                                Serial.println("Awaiting next command.");
    IsBusy = false;
    }
    else
    {
    ExecuteMovement();
    IsBusy = false;
                                Serial.println("Awaiting next command.");
    }
    }
}
void ProcessInput()
{
  if (stringComplete)
  {
    Serial.println(inputString);
    stringComplete = false;
    parse();
    inputString = "";
    IsBusy = true;
  }
}
void serialEvent() {
  while (Serial.available()) {
    // get the new byte:
    char inChar = (char)Serial.read();
    // if the incoming character is a newline, set a flag
    // so the main loop can do something about it:
    if ((inChar == '*')&& (inputString.length() > 1)) {
      stringComplete = true;
      inputString.toUpperCase();
      return;
    }
    // add it to the inputString:
    if((inChar >= 32) && (inChar <= 122))
      {
        inputString += inChar;
      }
  }
}
Function calls are properly defined elsewhere as well as datatypes ect.  As I stated before, this was a working program, however, I receive no echo when running on the Micro vs. UNO.
Logged

Atlanta, USA
Offline Offline
Edison Member
*
Karma: 55
Posts: 1812
AKA: Ray Burne
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
I receive no echo when running on the Micro

Do, it appears you have diagnosed a big issue!

Using the Micro-Leonardo, did the LUFA drivers load in the OS?  When connected, does the OS enumerate a Comm port?

Standard testing methodology ... Try different ports, use the OD device manager to check enumeration, swap called, etc.

http://fourwalledcubicle.com/blog/2012/08/lufa-and-the-arduino-leonardo/
Quote
you’ll need the driver INF file it contains in the arduino-1.0\drivers directory

Ray
Logged

Offline Offline
God Member
*****
Karma: 1
Posts: 547
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I can program the device, it posts correctly in device manager. A sketch that does not rely on serial communication runs as expected.
Logged

Atlanta, USA
Offline Offline
Edison Member
*
Karma: 55
Posts: 1812
AKA: Ray Burne
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
A sketch that does not rely on serial communication runs as expected.

... and you are using the Arduino Leonardo hardware profile?

There was a thread regarding serial comms on the Leonardo... may not be applicable, but you probably should consult just to be certain
http://forum.arduino.cc/index.php?topic=119557.0

Here are the loopback instructions:
http://forum.arduino.cc/index.php?topic=73748.0

Logged

Offline Offline
God Member
*****
Karma: 1
Posts: 547
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I am using the board profile for the Arduino Micro in the IDE 1.0.5.

I am getting RX data lights, but no indication of the application getting the data.
« Last Edit: January 01, 2014, 03:03:50 pm by ajofscott » Logged

Atlanta, USA
Offline Offline
Edison Member
*
Karma: 55
Posts: 1812
AKA: Ray Burne
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Do you understand that the Com port in Windows that you use to upload to the ProMicro is not the same com# that you will use to establish serial communication?

For example, the JPG attached shows the error that is normal after I uploaded on Com11 but tried to open the Serial Monitor window without changing to the new enumerated port Com13.  When I used Com13 (did not exist before I uploaded) the communications with the 32U4 went well @ the 9600 BAUD that I configured.

Ref: http://arduino.cc/en/Guide/ArduinoLeonardoMicro
Quote
However, because the serial port is virtual, it disappears when the board resets, the Arduino software uses a different strategy for timing the upload than with the Uno and other boards. In particular, after initiating the auto-reset of the Leonardo or Micro (using the serial port selected in the Tools > Serial Port menu), the Arduino software waits for a new virtual (CDC) serial / COM port to appear - one that it assumes represents the bootloader. It then performs the upload on this newly-appeared port.


So, to recap: You upload on one com# and you do serial on another com#.

Ray


* ProMicro.jpg (66.46 KB, 1280x800 - viewed 30 times.)
Logged

Offline Offline
God Member
*****
Karma: 1
Posts: 547
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I do know that and what I am telling you is the normal run port is present, connects to the serial monitor, can send data to the device, but beyond that it all goes south. I send a command like RP *, I should see the command echoed as well as the machine's cursor location. Even if I send a bogus command, it should echo back to the serial monitor. What I have not done yet is send a sketch that just prints to see if I can receive data. I know the serial data getting to the board is not being consumed  by the board as I have verb/value sets for testing the motors and it ignores even those. Data is getting there in part, seeing that it strobes the RXD lamp. I think it will prove to be how the serial event is generated on the Micro differs from that of the UNO.
Logged

Offline Offline
God Member
*****
Karma: 1
Posts: 547
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The issue as it turns out is that the chipset does not generate a call to serialEvent() when data arrives so adding this cured the dilema:
Code:
            if (Serial.available()>0)
            {
              serialEvent();
            }
Logged

Pages: [1]   Go Up
Jump to: