Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Shared COM1 Issues


  • Please log in to reply
9 replies to this topic

#1 Joshk

Joshk

    Advanced Member

  • Members
  • PipPipPip
  • 72 posts

Posted 28 September 2012 - 06:33 PM

I have a problem I am not sure how to Google it. I got my first netduino mini the other day and had a board ready to go. I soldered it in and updated it to 4.2. I can only load my software to it once, then I have to flash it because I can't communicate anymore. I am using a class from my netduino based on the SerialPortHelper found on this site and it works on netduino. So I suspect it is because I am doing something dumb trying to load software that configures the com1 when it boots since the mini debugs over com1 also. Com2 is not available at all for debugging because to connects to another chip on the board and would have the same problem. I miss the usb port :( Project summary: The Mini is supposed to operate the chip and send occasional information to a PC over RS232. Is my project possible? Thanks.

#2 awaiK

awaiK

    Advanced Member

  • Members
  • PipPipPip
  • 90 posts

Posted 28 September 2012 - 07:28 PM

Hi, yes, thats a problem. You have to reserve one COM port for debug and deployment. Maybe you can try the following: Define an interupt which dispose at least one of your COM ports to enable debug and deployment. The interupt can be trigged by an external switch.

#3 Joshk

Joshk

    Advanced Member

  • Members
  • PipPipPip
  • 72 posts

Posted 28 September 2012 - 11:44 PM

Thanks for the idea, that sounds like it will work. It raises another though... what triggers the debug more? Is there a character or set of characters that I need to avoid? Or can I even have some sort of control over the debug mode?

#4 Joshk

Joshk

    Advanced Member

  • Members
  • PipPipPip
  • 72 posts

Posted 01 October 2012 - 03:55 AM

That did not work as thoroughly as expected.
I added a bit of code so my code does not setup a COM if pin Digital_13 is low. That allows the debugger mode to work fine if I hold Digital_13 low during boot. But when running my code when the mini was sent data the DataReceived event was not firing. I discovered if I prevent the NEW function from finalizing the debugger would not get around to starting... so I jammed the NEW function with an indefinite thread sleep as the last line of code. Everything seems to still work, and DataReceived is firing every time I press a key, as confirmed by the data the mini is sending back to my terminal each time I press a key. But I can't seem to get the correct data out of the buffer. It seems the buffer is empty by the time the event fires. I did seriously tampered with the code during my testing, maybe I broke it, or maybe the buffer is being sucked empty by framework code first.

Any insight or advice?

Private Sub serialPort_DataReceived(sender As Object, e As System.IO.Ports.SerialDataReceivedEventArgs) Handles serialPort.DataReceived
        Try
            Dim Buffer As Byte() = New Byte(serialPort.BytesToRead - 1) {}
            serialPort.Read(Buffer, 0, Buffer.Length) 'Load "Buffer"
            Print(serialPort.BytesToRead.ToString)
            _buffer += New String(Encoding.UTF8.GetChars(Buffer))

            ' Have we received a full line of data?
            Dim Pos As Integer = _buffer.IndexOf("5")
            ' Data gets parsed
            If Pos >= 0 Then
                Dim Data As String = Me._buffer.Substring(0, Pos)
                Me._buffer = Me._buffer.Substring(Pos + 2)
                Print(Data)
                RaiseEvent LineReceived(Data)
            End If

        Catch ex As Exception
            Print(ex.ToString)
        End Try
    End Sub


#5 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 01 October 2012 - 04:22 AM

Just FYI...if you drive the DTR pin high during powerup, the Mini will go into TinyBooter mode so you can erase your app. Chris

#6 awaiK

awaiK

    Advanced Member

  • Members
  • PipPipPip
  • 90 posts

Posted 01 October 2012 - 10:48 AM

Thats a great info! Thanks Chris

#7 Joshk

Joshk

    Advanced Member

  • Members
  • PipPipPip
  • 72 posts

Posted 01 October 2012 - 01:45 PM

Yea that's really handy, thanks Chris. What are your thoughts on trying to run a program on a Mini that uses both Com ports?

#8 KodeDaemon

KodeDaemon

    Advanced Member

  • Members
  • PipPipPip
  • 63 posts

Posted 01 October 2012 - 07:01 PM

Just FYI...if you drive the DTR pin high during powerup, the Mini will go into TinyBooter mode so you can erase your app.

Chris


Wow, maximum basic stamp compatability!

#9 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 01 October 2012 - 08:24 PM

Yea that's really handy, thanks Chris. What are your thoughts on trying to run a program on a Mini that uses both Com ports?

Generally, you will want to reserve one serial port on Netduino Mini for a debug connection to the PC.

That said, I'm pretty sure that some users are using both serial ports in their applications. It's possible that NETMF support for this may have changed between NETMF 4.1 and NETMF 4.2, but I'm not aware of any specific changes.

One final note...if you're simply trying to send data to the PC from time to time, have you thought about using Debug.Print to do so? It will send the data over the serial port. Then you could parse that data out on the PC or use MFDeployEngine to capture the data post-parsing. As a bonus you wouldn't be blocking the debug port, so it would be easier to reconnect and redeploy your app.

Chris

#10 Joshk

Joshk

    Advanced Member

  • Members
  • PipPipPip
  • 72 posts

Posted 02 October 2012 - 04:38 AM

So basically I'm not trying hard enough but it's more trouble then it's worth. I will sacrifice some size and move up to the Netduino so I can focus on my goal. Thanks everyone for entertaining my idea. Sometimes it's hard to know the difference between clever ideas and lost causes. Places like this are great for sorting them out.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.