Reason 3.0 Serial Serial Key
Austin Vermont
I am trying to interface a contact-less smart card reader over UART (usbserial) using termios framework under Linux. The code works fine on the PC, but when I cross-compile and try it out on an ARM9 target, it is able to open the device and even writing the command to the device, but the read command blocks indefinitely. Here is the code snippet :
The mifare_1K structure contains the file descriptor for serial device, termios structure, and various buffers I am using. The device as I mentioned is usb-to-serial ( module: ftdi_sio ) device. It's configured at 38400@8-N-1 in Canonical mode of termios.
Another thing is that if I remove the card reader and connect that port to gtkterm (serial port terminal program) on another PC, I do not receive the "$1V\n" on that gtkterm ??!! . Then after a little RnD I found out that if I reboot the system on which the reader is connected reader then only I get that cmd "$1V\n" on the other Gtkterm. If I try again without a reboot, that cmd is not seen on that Gkterm...a clue, but havnt figured it out yet.
1) O_NDELAY is added to the flags in open() call, which ignores Data Carrier Detect (DCD) line to see if the other end is connected and ready for communication or not. This was used originally for MODEMs, which I did not need, in fact, I do not have it at all since I am using usbserial. But this flag also makes further calls to read() and write() as non-blocking. Point to note, I had thought this would be taken care of by adding CLOCAL to cflag of termios struct, which I had tried but did not work.
This combo is working perfectly for me. The only reason I am not posting this as an answer is that I do not yet understand why it worked on PC without this modification, since it was same hardware. In fact, I was able to read data from the smart card reader ON ARM9 TARGET using minicom , but not my program. I am going to check FT232BL docs to see if what is the status of DCD by default.
In my case the cause turned out to be a missing RTS flag. The Telegesis expects CRTSCTS flow control, and would not send any data to the Raspberry without seeing the RTS. The perplexing aspects here were that a) the same code works just fine on a PC, and b) it worked fine on the Raspberry the first time the Telegesis was plugged in, but on subsequent openings of /dev/ttyUSB0 no data would be seen by the Raspberry.
For some reason, it seems that on the ARM the RTS flag gets cleared on device close, but not set again, whereas on x86/x64 the RTS flag stays set. The fix here is simply to set the RTS flag if it isn't already - e.g.
I do note that in your case you don't use flow control, so the above may very well not be applicable. It was your question and the mentioning that minicom worked that led us to discover the solution to our problem however - so thank you for that!
These symbolic subscript values are all different, except that VTIME, VMIN may have the same value as VEOL, VEOF, respectively. In non- canonical mode the special character meaning is replaced by the timeout meaning. For an explanation of VMIN and VTIME, see the description of non-canonical mode below.
So please check if the definitions of these constants are different for your two platforms. It might be, that the EOL/EOF logic might be spoiled by the wrong setting. Both EOL and EOF migh cause a return from read.
Your code does not show a proper initialization of the c_cc array. You neither read the existing settings not provide suitable defaults for the values required for canonical modes. The code shown so far does not even clear the values. Therefore unpredictable values might be used.
Anyway, I've noticed that in my serial monitor window it will allow me to select up to 250k baud, and I've tested that my serial print()'s work just fine at that speed (with an appropriate Serial.begin of course).
Probably not, just remember if you post a program to put a comment like "set serial monitor baud rate to match" after Serial.begin(). Else you'll get replies of "Your program fills my serial monitor with garbage" because their's is set to the default 9600.
I don't know if it works with the Serial Monitor but 500,000 baud works very well with my Python programs. In the Atmel datasheet there is a table of all the baud rate options and the timing errors associated with them for different Arduino clock rates. At 16MHz and 8MHz 500,000 baud has no error.
Come to think of it though, I don't remember ever changing any settings in serial monitor when I first started using it. I was just always using 9600 and it always worked. So I believe that 9600 must have been the default when I first downloaded the software.
I honestly think 9600 causes more than often causes problems. I use 115200 as 'default' for my programs, don't know why. I was writing some IR software for a toy with the Arduino, 9600 baud caused too much delay at each Serial.print and there was no buffer on the IR sensor... It took ages to figure it out...
I tested this even over long cables (10m+) with no errors. My father used to work with intercity communications before the internet and they used 9600 because over longer distances (a few kilometers) higher baudrates had difficulties... So I can see why you would use it for that, but over a shielded short USB cable, the sky is the limit I say...
The 3 arduinos control up to 34 relays that control the venue lighting, and one of the arduinos has 6 sensors attached that sends the inputs back to processing. (two touch sensors, two buttons, one accelerometer and one motion sensor).
However, every time i startup the installation, it works for about 10-15 seconds, I see that processing stops receiving the serial data from arduino, and when i try to restart the programs, it says the port is busy.
I tried restarting the computer, but seems that the busy port is preventing the computer from shutting down, so I could only shut it down by holding on to the power button. It works again after i restart the machine but the serial communication drops again after 10-15 seconds.
Does your Processing program open and close the serial ports or do they remain open ? Opening a serial port attached to most Arduinos will cause them to reset and begin the program again. You can see this behaviour when you open the Serial monitor from the IDE.
For communications from Processing to Arduino, processing opens 3 serial ports, with the same port (9600), but with different names (according to the serial port name like "tty......1411" ), the serial ports remain open as long as the program runs.
Hmm.. I dont really remember coding anything complicated enough that could crash the arduino, maybe because of a program bug, but it seemed to be working fine when I tested it individually without the lights though.
Stop that crap right there. First, there is no reason to collect all the data into one variable before sending it. The receiving end can't tell you did that, and wouldn't care if it could. Second, there is no reason to wrap the char array that actually holds the data.
Are you sure about this ? I am not familiar with Processing but 9600 sounds suspiciously like the baud rate to me and it matches the baud rate in the Arduino code. How are the three serial ports in Processing connected to the single one on the Arduino ?
Are you sure that it is the Arduino which is crashing, and not the PC/Laptop/Processing code which is crashing - could it be that processing is not processing (!) the incoming data fast enough, and you are getting some sort of receive-buffer-overflow ??
The only long message I'm sending around is the arduino UNO sending back to Processing, which goes like this:
"#00000,000;"
First and last char is for verifying whether there are left out characters.
2nd - 6th char are I/O indicators of different sensors switches such as motion sensors, buttons, touch sensors
8-10 char is the value of the accelerometer
The arduino has a 30 millisecond delay between each loop. The message sends out whenever there is change in any of the sensors, however since the accelerometer values bounce around quite a lot even when it sits still, it pretty much sends out messages on every loop, even if I have already averaged out the values.
As for messages sent from the Processing to Arduinos, its just bytes like "201" with a "255" at the end, so arduino recognises its the end of the message.
The first digit is the phase of the program such as "sleep phase" "initiate phase" "active phase"
The others are just I/0 indicators of which phase the lights should be in.
It seems to work fine with my mac book pro running osx 10.7.5, but the machine that I'm supposed to run it on is a Mac Mini 10.9 and just keeps disconnecting after a few seconds and clogging up the port.
On the laptop, it still disconnects once in a while but not that often, but the port releases back out just fine when I close the program. However when I tried using a USB hub with external power, and matched the port names, it disconnects just like the mac mini which is strange.
I actually brought the Mac mini to an apple technician to ask what could potentially be the problem, he said that the ports seem fine, and said maybe the OS has collided the port addresses, and he could downgrade it 10.8.5 for us to see if it works.
I'm suspicious that because the arduino that sends the sensor data to processing is the same one that is receiving data form processing. Therefore the messages are colliding into each other and freezing the serial port
Serial Port : Serial communication takes place asynchronously, meaning that no synchronization signal (or clock) is required: the data may be sent at random intervals. In return, the peripheral must be able to distinguish the characters (one character is 8 bits in length) among the succession of bits which is sent.This is why, in this type of transmission, each character is preceded by a START bit and followed by a STOP bit. These control bits, which are needed for serial transmission, waste 20% of the bandwidth (for 10 bits sent, 8 are used to code the character and 2 are used for reception).
b1e95dc632