chipKIT® Development Platform

Inspired by Arduino™

Serial Bug on MAX32

Created Fri, 29 Mar 2013 14:53:37 +0000 by sammy_k


sammy_k

Fri, 29 Mar 2013 14:53:37 +0000

Hello,

While attempting to port the LabVIEW Interface for Arduino to chipKit I ran into an issue where serial data was not being sent from the chipKit (however it was being received). I have reproduced this on the MAX32 but I don't currently have an Uno32 to test this on.

I've created a (relatively) simple example to reproduce the issue. The example code waits for 15 (COMMANDLENGTH) serial bytes (one packet). When a full packet is received the data is copied to a buffer (currentCommand[]) and a response is sent by calling respond(). Certain alterations to the code prevent the respond() function for printing serial data. For example uncommenting the delay(1) indicated below prevents serial data from being transmitted. I havn't had a chance to hook it up to the debugger, but I assume there is an issue with the serial ISRs.

It would be great if someone from digilent could take a look at this and let us know if there is a fix. The work around of adding delay(1) does not always resolve the issue and seems to depend on the surrounding code.

Thanks!

-Sam K

Apparently you cannot attache a .pde file to these posts...so here is the code.

/*************************************************************************************************
* This code demonstrates an issue with serial transmission on the chipKIT Max32 (I suspect the 
* issue is related to serial interrupts, but I have not had a chance to hooked it up to a debugger 
* to confirm).
*
* The code below waits for 15 (COMMANDLENGTH) serial bytes (one packet).  When a full packet is 
* received the data is copied to a buffer (currentCommand[]) and a response is sent by calling 
* respond().  Certain alterations to the code prevent the respond() function for printing serial
* data.  For example uncommenting the delay(1) indicated below prevents serial data from being 
* transmitted.
*
*************************************************************************************************/
#define COMMANDLENGTH 15
unsigned char currentCommand[COMMANDLENGTH];
unsigned int loopCount;

void setup()
{
  Serial.begin(115200);  
  pinMode(13, OUTPUT);
}

void loop()
{
  //Blink LED
  digitalWrite(13, ((loopCount / 100000)%2));
  loopCount++;
  
  if(Serial.available() >= COMMANDLENGTH)
  {
    for(int i=0; i<COMMANDLENGTH; i++)
    {
      currentCommand[i] = Serial.read();
    }
    /*************************************************************************************************
    * Comment the delay(1) below and the respons() call will never send serial data.
    *************************************************************************************************/
    delay(1);
    respond();   
  }
}

void respond(void)
{
  Serial.print("Good Command");
}

majenko

Fri, 29 Mar 2013 19:22:06 +0000

Works perfectly fine on my UNO32 - what version of the IDE are you using?


sammy_k

Mon, 01 Apr 2013 14:57:53 +0000

I'm glad to hear it works on the Uno32.

I'm using v20120903 of the MPIDE

-Sam K


sammy_k

Mon, 08 Apr 2013 19:25:08 +0000

I tested this on my Uno32 this weekend and while the issue does not reproduce with the test code above, it still does in my end application.

The end application is the LabVIEW Interface for Arduino (LIFA) running on Chipkit. I have working firmware posted here:

https://github.com/labviewhacker/lifa/tree/master/LabVIEW/vi.lib/LabVIEW%20Interface%20for%20Arduino/Firmware/ChipKit

In that folder is a stripped down version of the LIFA firmware that should be compatible with the Chipkit Uno32. It builds and deploys fine and receives serial data from the host PC, however it never sends any response.

To work around the issue I've added a delay(1) to line 95 of LabVIEW Interface.ino. Adding this delay causes the Uno32 to both receive and send serial data and the LIFA toolkit is fully functional (but runs a bit slower due to the unnecessary delay).

Without digging into the Uno32 Serial library my best guess is a serial interrupt issue. Does anyone have any ideas?

Thanks!

-Sam K