11 replies to this topic

[louyo]

Lazy man's question: Did something change with the com ports between Netduino Plus and Netduino Plus 2? I moved a working application from the Plus to the Plus2 and it fails in the com port routine. Tried both 1 and 2. If there is no known problem, I will carry on debugging.

 

Louyo

[ziggurat29]

I use 3 serial ports in my app on the plus 2, and it runs in the field for some months now, so maybe carry on debugging.

 

However, I cannot speak to the part about changes from NP to NP2'.  The Plus to Plus 2 invoked a processor change, of course.

 

I personally experience unreliable firing of DataReceived, and I altered my design to not use events, and things have been solid since.  Others have reported similar problems, but the root cause it unclear to me since the stimulating circumstances vary (usually something like 'when i use ethernet, serial stops working after a while') etc.

 

I'm curious to know more about the nature of your problem, especially if its a sporadic issue at runtime.

[louyo]

I'm curious to know more about the nature of your problem, especially if its a sporadic issue at runtime.

It works fine on an NPlus but failed solid on Plus 2. Will have to debug. It goes through the speed check and then gets an unhandled exception. Will have to find where and catch it. Camera application. 

Thanks for the reply.

Louyo

[ziggurat29]

OK and at the risk of confusion, I don't know what the RX buffer size is on the Netuduino Plus, because I don't have the firmware source for that, but for the NP2, that buffer size is 256.  I mention this because it's smaller than on the N2 (where it is 512), so /maybe/ that could be a difference.

[Chris Walker]

Hi louyo, What configuration settings are you using for your SerialPort object? The SAM7X did support a few more combinations of data bits and parity. Most Netduino gen1 projects using SerialPort should function the same on Netduino gen2. Chris

[louyo]

Hi louyo, What configuration settings are you using for your SerialPort object? The SAM7X did support a few more combinations of data bits and parity. Most Netduino gen1 projects using SerialPort should function the same on Netduino gen2. Chris

Thanks, I will have to get back here when I can take a look. Day job is in the way, and the device is not here.

 

Louyo

[louyo]

Hi louyo, What configuration settings are you using for your SerialPort object? The SAM7X did support a few more combinations of data bits and parity. Most Netduino gen1 projects using SerialPort should function the same on Netduino gen2. Chris

Parity:None, 8 bits, one stop bit, various baud rates, both ports (com1 and 2).

It is failing in the ReadResponse function, with an Unsuported length exception. It reads the framelength and then goes through about 2 more readresponse operations and then throws an exception on this line of code:

var bytesRead = _comPort.Read(_response, _responseIndex, expectedResponseLength);

 

Debugging is slow because:

1. I copied the code from AdaFruit (I think) and am figuring it out as I go.

2. Putting debug stuff in there sometimes causes timeouts.

3. I am in the slow group.

 

It seems to me that the error is from calling the _comport.Read routine with different values for the responseIndex and expectedResponseLength, but am still pursuing. 

 

It seems like it is not a configuration problem but I am unsure of anything at the moment. 

I was hoping someone was using this camera on a +2. 

Thanks again,

Lou

[Chris Walker]

Hi Lou, When you get the exception, how many bytes long is _response? What are the values of _responseIndex and expectedResponseLength? Chris

[louyo]

Hi Lou, When you get the exception, how many bytes long is _response? What are the values of _responseIndex and expectedResponseLength? Chris

Response index is 4, expectedResponseLength is 1

_response is 21 bytes long 

 

Louyo

[Chris Walker]

Hmm, that is really bizarre. It should just be pulling in one byte for you. If there's a way for us to repro this here (i.e. feed it data via HyperTerminal instead of via a physical device), we'd be happy to try to repro. Chris

[louyo]

Hmm, that is really bizarre. It should just be pulling in one byte for you. If there's a way for us to repro this here (i.e. feed it data via HyperTerminal instead of via a physical device), we'd be happy to try to repro. Chris

10-4, thanks for the offer. I will muddle along as I have time, I have moved back to NP as it works there. I didn't get the storage improvement that I hoped for on NP2 anyway. The speed improvement is nice though. I need to go back in and trim more of the code I don't need. 

Thanks again,

Lou

[louyo]

Hmm, that is really bizarre. It should just be pulling in one byte for you. If there's a way for us to repro this here (i.e. feed it data via HyperTerminal instead of via a physical device), we'd be happy to try to repro. Chris

OK, another update. I put a  debug print statement in the routine that gets data from the camera and writes it to the file. I wanted to see how much it read before it crashed. It read the whole thing! The file it wrote, however, was corrupt, not a valid jpeg. That routine gets 120 bytes from the com port and then opens the file, writes the 120 bytes and closes the file (maybe).

SWAG:

It seems to be an: async, reentrant or plain old timing problem and part of the problem is the streamwriter closing thingie, see that thread. This is brought  on by the faster processor. So, for a workaround, one is going to have to find all the asynchrous stuff (or renentrant) and make sure to block until it finishes.

Just my SWAG.

My current "fix" is to press on with my N+ and leave the N+2 for another set of SDK/firmware.

Thanks for taking the time to help those of us mired in the slow group.

 

Louyo