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

Serial Port Reader Erros


  • Please log in to reply
5 replies to this topic

#1 logicalstep

logicalstep

    Member

  • Members
  • PipPip
  • 21 posts

Posted 29 January 2012 - 04:16 PM

Hi all, I hope someone can help. I'm trying to read Tag Id and Ascii responses from an RFID reader. It send the Tag ID over the Serialport fine, and then I send back a request to start further processing, however the Tag ID arrives fine the first time, but subsequent requests seem to be missing data. So my question is... does the 'port.Read(bytes, 0, port.BytesToRead);' Read in all the bytes from the Serial Port, or just the ones that have arrived since you have reached the Break point? I have already done a program in VB that essentially does a lot of what I'm trying to do and on the VB serial port class, I can set it to keep reading the serial port until there are no bytes to read left. This way I know it's not a timing issue, but on .Net Micro there doesn't appear to be a way to do this, you have to just read in what's there in one chunk. I've tried inserting a small delay before reading the bytes, as I know sometimes it need a moment to 'finish' reading the bytes. So Here is what I have: (for now I have just dimensioned the Holding Byte Array statically to 40 Bytes). static void RecievedData(object sender, SerialDataReceivedEventArgs e) { Thread.Sleep(100); string line = ""; byte[] bytes = new byte[40]; ByteToReadGlob = port.BytesToRead; port.Read(bytes, 0, port.BytesToRead); if (ByteToReadGlob == 11) { SentReq = true; ComSend(":002000" + (Char)13); } else { if (SentReq) { string rcvd = ""; SentReq = false; rcvd = new string(Encoding.UTF8.GetChars(bytes)); Debug.Print("Worked Rcvd " + rcvd); } } ByteToReadGlob = 0; //line = "" + new string(Encoding.UTF8.GetChars(Storbytes)); //Debug.Print(line); //line = "" + new string(Encoding.UTF8.GetChars(Storbytes)); //Debug.Print(line); } }

#2 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 29 January 2012 - 05:14 PM

Hello Logicalstep.
The "Read" method halts the program execution until one of the following conditions are met:
  • in the serial receiving buffer there are at least NRX bytes (in your case is BytesToRead);
  • a period equals to ReadTimeout passed.

The serial UART is basically a shift register, converting the serial bit sequence to a parallel array of bytes.
Thus the hardware cannot "avoid" that some bad sequence of bit (e.g. due to noise) is incoming, simply the hardware layer signals an error, and the proper decision has to be chosen by the user (i.e. the programmer).

A good practice, either for physical/hardware and for software/firmware, is to use the "idle" as the "no-data" condition. The "break" is a particular condition, which should be used only when needed. Often the physical layer is not able to guaranteed this practice, and you should "keep" as idle even the breaks.

Hope it helps.
Cheers
Biggest fault of Netduino? It runs by electricity.

#3 logicalstep

logicalstep

    Member

  • Members
  • PipPip
  • 21 posts

Posted 29 January 2012 - 08:44 PM

Hi Mario, Thanks for your reply. So are you saying the program waits until the Bytes to read condition is met? port.Read(bytes, 0, port.BytesToRead); I thought that port.ByteToRead was giving me the number of bytes in the UART Buffer, not that this was a condition to be met by the program? The issue is that the RFID device I'm using isn't giving me bad data as it works fine with the VB PC version. So the only thing left is that I'm not getting all the data back, due to some other communication factor. I've had my share of Serial issues before and usually it's down to timings and settings, but in this case I'm pretty sure I have the settings all sorted. I'm not saying it's not something I've done, but is is possible that there is a reliability issue with the Firmware? Logicalstep

#4 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 29 January 2012 - 08:58 PM

When you read data from the serial port, it should return immediately if there are any bytes available--and return the number of bytes received. If there are no bytes available, it will wait for some...until the timeout period expires. Finally...if the port gets closed while you're waiting for data...the call should also return immediately. Chris

#5 logicalstep

logicalstep

    Member

  • Members
  • PipPip
  • 21 posts

Posted 29 January 2012 - 09:22 PM

Thanks Chris, Yes as you describe it is what I'm expecting to see, however the bytes I'm getting back seem very erratic. Sometimes it even works and sends back what I think it should. I'm really struggling to get this working, when really it should be a fairly simple operation, at least in terms of sending and receiving very small amounts of data. The device I'm comms'ing with required Ascii codes, however I'm using UTF8 and converting the string to bytes using this method. Am I right in thinking that Ascii is just a subset of UTF8 and as such shouldn't be causing the issue? To be fair I'm seeing what I would expect in terms of Bytes I'm sending. The only thing I can think is that I'm using the wrong TTL to 232 chip and that it's fine until it requires to do things at a faster speed? I'm using a HIN232IPZ...just looking now it shows it as a 5V chip..could this be the cause? what are the Uart voltages on the Netduino? Many thanks. Logicalstep

#6 logicalstep

logicalstep

    Member

  • Members
  • PipPip
  • 21 posts

Posted 29 January 2012 - 10:39 PM

Ok well it appears it was my own stupidity that caused this, so in case anyone else does the same thing, the problem was caused by me having an LED on both the RX and TX lines to see when data was flowing. Without running them through a Transistor. I guess this was dropping the voltage levels enough to cause data errors! Thanks to Chris on Chat for the help. :) Logicalstep




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.