moin @ all,
ich bin gerade dabei eine RGB-LED-Leiste von meinem Computer
anzusteuern.
Dafür habe ich ein Arduino Nano programmiert und über die vorhandene
uart Schnittstelle und den Wandler an einen USB-Anschluss meines
Computers angeschlossen.
Zum Test habe ich mit minicom meine Befehle an den arduino geschickt.
Diese werden richtig interpretiert.
Daraufhin habe ich ein Programm für den Computer aufgesetzt, was minicom
ersetzen soll und später des weiteren eine grafische Oberfläche anbieten
soll.
Hier fängt es mit meinen Problemen an.
Ist minicom im Hintergrund gestartet, kann ich Befehle senden, die
interpretiert werden. Ist minicom nicht gestartet, so bekomme ich nach
dem Schreiben beim "select" einen Timeout.
Anbei ist mein Code.
Ich habe bereits die Konfiguration des Ports mit stty getestet.
Die Ausgabe nachdem minicom gestartet worden ist:
Soweit wie ich sehe, sind die Ausgaben identisch.
Meine Frage: wo ist der Fehler? :-) Die Kommunikation zwischen Computer
(minicom) und arduino nano funktioniert. Es muss an meiner Konfiguration
im Programm liegen...?
Hi,
Danke für deine Antwort.
Ich habe eine udev Regel erstellt. Diese erstellt diesen symlink.
Wir oben schon geschrieben, die Kommunikation funktioniert, wenn minicom
in Hintergrund offen ist... nur wenn minicom nicht läuft, funktioniert
dir Kommunikation nicht. Dann kommt bei select ein timeout...
Der select()-Aufruf ist IMO nicht korrekt. Der erste Parameter is
"nfds".
"man select" sagt dazu:
1
The first nfds descriptors are checked in each set; i.e., the descriptors from 0 through nfds-1 in the descriptor sets are examined. (Example: If you have set two file descriptors "4" and "17", nfds should not be "2", but rather "17 + 1" or "18".) On return, select() replaces the given descriptor sets with subsets consisting of those descriptors that are ready for the requested operation. Select() returns the total number of ready descriptors in all the sets.
danke für deine Hilfe.
Tatsächlich war mein select Aufruf verkehrt.
Leider hat das nicht mein Problem behoben...
Inzwischen habe ich den Bus mit einem LA mitgeschnitten.
Die Übertragung funktioniert einwandfrei. Jedoch wird danach aus einem
mir unbekannten Grund eine zusätzliche Flanke gesendet, parallel zu der
des ICs.
Ich vermute, dass hier das Problem herkommt.
Interessanterweise wird diese Flanke weder von IC noch vom Computer
gesendet, wenn minicom parallel geöffnet ist.
Wer kann mir sagen, was das für eine Flanke ist und wo sie herkommt?
Das i-tüpfelchen wäre dann noch, wie ich sie los werde ;-)
Jeder Hinweis wird gerne in Empfang genommen.
Fabian S. schrieb:> Die Übertragung funktioniert einwandfrei. Jedoch wird danach aus einem> mir unbekannten Grund eine zusätzliche Flanke gesendet, parallel zu der> des ICs.> Ich vermute, dass hier das Problem herkommt.>> Interessanterweise wird diese Flanke weder von IC noch vom Computer> gesendet, wenn minicom parallel geöffnet ist.>> Wer kann mir sagen, was das für eine Flanke ist und wo sie herkommt?>> Das i-tüpfelchen wäre dann noch, wie ich sie los werde ;-)>> Jeder Hinweis wird gerne in Empfang genommen.
Je nachdem ob du die China Version von deinem saleae benutzt, kommt es
durchaus vor, das du ein "überspringen" hast. Wenn dann wäre da ein
gewaltiger zoom interessant. Wenn der Ausschlag nur für eine clk oder so
ist, würde ich behaupten es gilt der Satz: "Wer misst misst Mist"
Ich habe die originale Version.
Es ist tatsächlich nur 1 Clock lang.
Faszinierend ist aber, dass der Controller mit diesem Peak nicht so
agiert, wie er soll.
Ist Minicom im Hintergrund geöffnet, erscheint das Peak nicht und der
Microcontroller agiert so wie er soll...
ich glaube an das Peak, das ich hier auch messen konnte. Die Frage ist
und bleibt: wo kommt es her? Also was exakt fabriziert der Computer, was
er eigentlich nicht soll...?
An meinem Code hat sich im Prinzip nichts geändert. Ich habe einige
Flags noch mal hinzugefügt / weg gelassen. Das Prinzip ist immernoch das
gleiche.
Ich schicke bereits LF / CR mit.
Das hier ist meine Main...
Ich habe es gerade auch mit \r ausprobiert, bzw \r\n, \n\r.
int main(int argc, char *argv[])
{
terminal serialport;
char data[16] = "1:0,0,0!\n";
serialport.send(&data[0]);
usleep(10000);
memset(&data[0],0,16);
data[15] = '\0';
serialport.receive(&data[0]);
serialport.~terminal();
return 0;
}
Keine Änderung...
Nur ein Verdacht. Kann es sein, das Minicom dir dein TTY konfiguriert
und du ggf. ohne Minicom mit der falschen Baudrate oder dem falsche
Bitsetting arbeitest?
meine Vermutung ist diese. Jedoch habe ich bereits 5 unterschiedliche
Beispiele aus dem Internet kopiert. Diese nach erstmaligen ausprobieren
meiner Meinung nach angepasst. Es hat nie etwas funktioniert.
Die Baudrate passt, zumindest die ich auswähle.
Auf dem Bus sieht auch alles passend aus.
Ich hab bereits öfters mit stty -aF /dev/ttyPWM0 (ttyPWM0 ein Zeiger mit
Zugriffserlaubnis für Nutzer auf ttyUSB0) die Ausgabe nach minicom und
nach dem Programm angeschaut, sieht identisch aus.
Aktuell vermute ich, dass ich zu schnell schicke und der Atmega nicht
hinterher kommt... somit würden daten verloren gehen auf dem weg.
