I've written some code that successfully reads input voltage on the analog pins, formats that voltage into a string, and then serial-prints it out. On the actual full UNO R3, I can read the serial data both through the arduino software in windows, and also reading the terminal directly in linux.
#define LED 13
void setup() {
Serial.begin(9600);
}
float mapfloat(float x, float in_min, float in_max, float out_min, float out_max)
{ return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min; }
void loop() {
if (Serial.available() > 0) {
// collect this info, but don't do anything with it.
int thisChar = Serial.read();
while (1) {
int sensorValue00a = analogRead(A0);
float sensorValue00b = mapfloat(sensorValue00a,0.00,650,0.00,100.00);
int sensorValue01a = analogRead(A0);
float sensorValue01b = mapfloat(sensorValue01a,0.00,650,0.00,100.00);
int sensorValue02a = analogRead(A0);
float sensorValue02b = mapfloat(sensorValue02a,0.00,650,0.00,100.00);
int sensorValue03a = analogRead(A0);
float sensorValue03b = mapfloat(sensorValue03a,0.00,650,0.00,100.00);
Serial.print("VALUES,");
Serial.print(sensorValue00b);
Serial.print(",");
Serial.print(sensorValue01b);
Serial.print(",");
Serial.print(sensorValue02b);
Serial.print(",");
Serial.println(sensorValue03b);
}
}
}
Not the prettiest code; this is just thrown together to provide the data I want. This gives me precisely what I want on the normal full UNO, and it's fast output, which I need.
I built a barebones Arduino (Atmega328p-pu, USB-TTL circuit, 2 caps+16crystal, and a reset button for good measure), and I have successfully burned the script onto the board, and I receive the input over the serial connection. But... it wasn't as zippy as the full UNO.
I needed to know if there was something up with my wiring, or if the USB-TTL converter was causing the slowdown. The easiest way to isolate the problem was to connect the full UNO to the USB-TTL and pull in the data through it. I wired the USB-TTL directly to the full UNO to the computer, using the rx/tx pins on the full UNO.
Sure enough, the USB-TTL is creating some kind of bottleneck. It's a much slower communication stream.
However... the bigger problem is that there appears to be some kind of buffer overflow issue, because in addition to the slowdown in the data stream, after about a minute of data, the data stream turns into a garbled mess. Complete jibberish. This is the case whether I run the barebones arduino or the the full UNO across the CP2012. After a while of running the code, the serial output gets all garbled.
So... is there a known issue with the CP2012 module that causes some kind of corruption of the data? Is there a better way to write my code to perhaps reset the data buffer or whatever to get it to start over?
Thanks!