bearing: Varför skulle serie rutinen ta så lång tid på sig? Det är dock inte extremt strikt med uppdateringen, om det blivit 9 eller 10 hade inte spelat någon större roll och det visade sig sedan också att om jag uppdaterar displayen 10 ggr/s så blir det inte helt oväntat gröt av siffrorna då ju LCD:er inte direkt är kända för sin snabbhet så jag var tvungen att dra ner det till 5 ggr/s som var helt perfekt.
Jag kanske ökar det lite sedan beroende på hur många decimaler jag kommer att använda mig av då det inte kommer att uppdateras lika snabbt om jag använder färre men en flimmerfri display är ju alltid fint.
Men det visade sig sedan faktiskt inte funka helt ändå pga att jag (föga överraskande) visade sig inte helt visste hur seriebufferten funkade. Jag trodde i min enfald att den tog datan som fanns och höll den tills nästa data kom då föregående direkt skrevs över, men så var visst inte riktigt fallet.
Om jag förstod det hela rätt så tar emot datan och behåller den ja, men sedan gör den inte ett dyft mer än till efter att en viss tid förflutit oavsett om det kommer mer data eller ej och detta hette visst något så enkelt som, Serial.setTimeout och som standard är detta satt till hela 1 sek så inte så konstigt att inget funkade oavsett vad. Efter att jag satt det som test till 50 ms så funkade dock allt precis som det skulle, i alla fall så som jag tänkt vls och testat i IDE med seriemonitorn.
Koden nu om någon vill se skiten:
Kod: Markera allt
void loop() {
Serial1.print("@254PR3?;FF");
delay(200);
if (!Serial1.available()) {
lcd.setCursor(8, 0);
lcd.print("NO DATA");
}
else {
value = Serial1.readString();
lcd.setCursor(8, 0);
for (int mod = 7; mod < 14; mod++) {
lcd.write(value[mod]);
}
}
}
Koden funkar det jag testat.
Den kod du nämner lillahuset tror jag att jag kopplar principen bakom (är dock helt grön på detta men inte planerat att lära mig mer än nödvändigt) och det hade säkert funkat det med så den sparas, tackar.