Hallo,
Ich habe hier einen Sparkfun Pro Micro. Der Mircocontroller hat den
Vorteil dass er als USB-Gerät verwendet werden kann. Weil ich dachte
dass das irgendwie "out of the box" funktionieren würde habe ich die
Arduino-IDE (unter Linux) genommen. Leider kann ich kein Programm
hochladen.
Ich bekomme folgende Ausgabe:
Der Sketch verwendet 6.042 Bytes (21%) des Programmspeicherplatzes. Das
Maximum sind 28.672 Bytes.
Globale Variablen verwenden 362 Bytes des dynamischen Speichers.
avrdude: ser_open(): can't open device "/dev/ttyACM0": Permission denied
avrdude: ser_send(): write error: Bad file descriptor
Das Wundert mich doch sehr, es scheint mir als hätte ich genügend
Rechte:
$ls -lah /dev/ttyACM0
crw-rw---- 1 root dialout 166, 0 Okt 30 23:01 /dev/ttyACM0
$id
uid=1002(rtzui) gid=1002(rtzui) Gruppen=1002(rtzui),20(dialout)
Ich kann auch einfach völligen Blödsinn in das Gerät schreiben (ich
hoffe es verzeiht mir das):
$ echo "test" >/dev/ttyACM0
$
Das einzige Programm was nicht dort hinschreiben zu können scheint ist
AVR-dude, und das wäre das einzige was mich interessiert.
Mit chmod Berechtigungen oder Eigentümer ändern geht wohl auch, udev
scheint die Berechtigungen fest festzulegen.
Kann mir hier jemand helfen?
Rtzui
Auf meinem Linux läuft AVRDude auch nur mit Admin-Rechten, d.h. ich
starte ihn mit "sudo" von der KommandoZeile aus - läuft also außerhalb
der IDE (bei mir "Codeblocks")
Ja, als Root funktioniert es. Aber das kann für mich keine Dauerhafte
Lösung sein. Das soll von Leuten (Kindern) bedient werden die definitv
kein Root sein dürfen.
rtzui schrieb:> Ja, als Root funktioniert es.
Dann ist es ziemlich sicher ein permissions Problem und wir können in
diese Richtung weiter suchen.
Welche Distribution benutzt du?
Ist eventuell SELinux, AppAmor oder ähnliches aktiviert?
Hast du nach dem du den user zur Gruppe dialout hinzugefügt hast dich
ab- und wieder angemeldet?
rtzui schrieb:> Das soll von Leuten (Kindern) bedient werden die definitv> kein Root sein dürfen.
Müssen Sie ja auch nicht... einfach die Anwendung mit sudo starten und
gut. Wo ist das Problem?
Alternativ den Owner auf root setzen, und das Userbit setzen, dann wird
das programm immer mit den Rechten des Owners ausgeführt, egal wer es
aufruft.
Oder per udev entsprechende berechtigungen beim mounten des devices
setzen, oder, oder, oder...
ich hatte den selben fehler in der arduino IDE, war auch in der gruppe
dialout, /dev/ttyACM0 war ebenfalls 0760, als root gings. das selbe
eben.
was geholfen hat war der von kaj gepostete vorschlag: udev rules.
1
@devel:~$ cat /etc/udev/avrisp.rules
2
# diese datei ist /etc/udev/avrisp.rules
3
# link anlegen "ln -s /etc/udev/avrisp.rules /etc/udev/rules.d/60-avrisp.rules"
Ich habe Ubuntu 14.4. Appamor ist (standartmäßig) installiert, weiß aber
ehrlich gesagt nicht wie ich es bedienen kann und ob es Zugriffe auf den
Port verhindert oder nicht.
Ich sehe zwar nicht Welche mehr Rechte die Berechtigung 666 gegeüber der
jetzt vorhanden Berechtigung 661 bringen soll, aber gut, ich hab mal
versucht es umzustellen.
Bislang sieht es so aus:
crw-rw---- 1 root dialout 166, 0 Okt 31 10:38 /dev/ttyACM0
Das Gerät wird von lsusb als
Bus 001 Device 042: ID 2341:0036 Arduino SA
Angezeigt, also habe ich eine Datei /etc/udev/rules.d/micropro.rules mit
dem Inhalt
ATTR{idVendor}=="2342", ATTR{idProduct}=="0036", MODE="666",
GROUP="dialout"
Angelegt und mit udevadm control --reload-rules die Regeln neu geladen,
das ändert aber nichts an den Berechtigungen der Datei. Auch
KERNEL=="/dev/ttyACM0", MODE="666"
ändert nichts.
Einerseits war ich schon immer ein Fan von udev (fast noch besser als
Pulseaudio), und das tut nicht was es soll, anderseits glaube ich auch
nicht dass des an den Berechtigungen liegt.
Ich wäre für weitere Ideen dankebar, speziell zu Appamor.
Rtzui
rtzui schrieb:> can't open device "/dev/ttyACM0": Permission deniedrtzui schrieb:> glaube ich auch> nicht dass des an den Berechtigungen liegt.rtzui schrieb:> Ja, als Root funktioniert es.
rtzui schrieb:> Ja, als Root funktioniert es. Aber das kann für mich keine> Dauerhafte> Lösung sein. Das soll von Leuten (Kindern) bedient werden die definitv> kein Root sein dürfen.
Google doch einfach mal nach dem Problem. Das ist doch wohlbekannt.
Füge dich zur Gruppe "dialout" hinzu.
Alexander S. schrieb:> Bernd K. schrieb:>> Füge dich zur Gruppe "dialout" hinzu.>> rtzui schrieb:>> $ls -lah /dev/ttyACM0>> crw-rw---- 1 root dialout 166, 0 Okt 30 23:01 /dev/ttyACM0>> $id>> uid=1002(rtzui) gid=1002(rtzui) Gruppen=1002(rtzui),20(dialout)
Dann wirds auch funktionieren. Problem gelöst.
Ich bin Mitglied der Gruppe dialout. Und nein, ich glaube nicht dass es
an den (Datei-)Berechtigungen liegt, zumindest fällt mir keine Sinnvolle
Erklärung dazu ein. Wenn ihr Glaub zu wissen woran es liegt, schriebt es
doch einfach.
Ansonsten wäre ich tortzdem an einer Erklärung interessiert wie ich die
Berechtigungen von /dev/ttyACM0 ändern kann.
Appamor o.Ä. könnte ich mir deutlich eher vorstellen, aber da habe ich,
wie gesagt, keine Ahnung von.
Rtzui
Ich habe mich an und ab-gemeldet, wie man an der Ausgabe von `id` sehen
kann. Scheint aber aus irgendeinem Grund nicht gereicht zu haben. Nach
einem Neu-Boot funktioniert das Programmieren. \o/
Wenn man bei udev die falsche Vendor-ID angibt kann es natürlich nicht
funktionieren. m(
Mit der Angegeben Zeile kann ich jetzt zwar den Owner und die Gruppe
ändern, der Modus bleibt aber immer 166. Ist aber glaube ich auch egal,
programmieren funktioniert ja.
Jetzt habe ich nur noch das Problem dass ich mit dem controller nicht,
wie versprochen, wenn das Programm läuft, über einen USB-emulierten
seriellen Port unterhalten kann. lsusb zeigt schlicht kein Gerät an.
Aber hier ist vermutlich das Programm, die library oder der Bootloader
schuld und nichts am PC.
Ok, und schon ist wieder alles hin. Das ganze hat genau ein mal
Funktioniert. Jetzt lautet die Fehlermeldung
Caused by: jssc.SerialPortException: Port name - /dev/ttyACM0; Method
name - openPort(); Exception type - Port busy.
Einziger Vorschlag den ich bislang so recht gefunden habe war
ENV{ID_MM_DEVICE_IGNORE}="1"
in die udev regel zu schreiben. Das bringt aber auch nichts.
lsof listet keine /dev/ttyA* Datei als offen.
Hast du den Controller schon ab- und wieder angesteckt?
Ist dein Controller im Programmier- oder Bootloadermodus?
Am besten dazu auch mal die Problemelösungen vom Arduino Leonardo
durchlesen. Ist der Gleiche Controller und der macht beim Programmieren
manchmal Probleme.
rtzui schrieb:> Port busy.
Wirf den Modemmanager aus dem System raus. Der glaubt auch im Jahr
2015 noch, dass jedermann TCP/IP über Modems machen wöllte und stürzt
sich deshalb nach dem Anstöpseln eines /dev/ttyACM* erstmal für ein
paar Sekunden auf dieses, um dann irgendwann festzustellen, dass ihm
ja doch nur niemand was dafür vorgegeben hat, das er tun könnte.
Mit dem Rauswerfen des Modem-Managers klappt jetzt das Programmieren
wieder \o/
Danke für den Tip. Und dem Rest auch Danke.
Jetzt so richtig funktionieren tut es aber immer noch nicht, uns so
lagsamm passt der Threadtitel Endgültig nicht mehr.
Also der clue von einem Pro Mikro ist ja der dass dieses Gerät ein USB
Gerät, z.B. eine Maus sein kann. Das Dingen Meldet sich als 3 USB-Geräte
(Eine Tastertur, eine Maus und ein Com-Port der wohl das leidige
Debuggen ohne JTAG erträglicher machen kann). Nur leider erkennt mein
Linux keines dieser Geräte. Habe jetzt genau das selbe Problem wie
Beitrag "Arduino Pro Micro zickt nach Umbau auf 3,3V/8MHz" Nur dass ich nichts
umgebaut habe, sondern direkt als 3.3V Version gekauft habe. Tja... so
ist das, nichts geht. Vielleicht baue ich dann auf 5V um, wenn das im
Ruf steht besser zu klappen.
Ich bin Echt kein Hardware-Mensch Vermutlich weil mich eine Aura umgibt
die Unglück bringt und Dinge kapput macht. Aber das versuche ich ja
gerade zu ändern, und die Aura scheint langsamm kapput zu gehen.
Jetzt geht alles, auch die Serielle Konsole. Ohne dass ich was geändert
habe.
Nochmal danke an alle.
Du solltest ihn nicht umbauen, besorge dir einfach einen mit 5V.
http://www.ebay.de/itm/291548871778
Ein Board kostet 2 Euro und hat gleich einen USB-UART-Konverter.
rtzui schrieb:> Also der clue von einem Pro Mikro ist ja der dass dieses Gerät ein USB> Gerät, z.B. eine Maus sein kann.
Bist du dir da sicher?
Da braucht man doch einen ATmega32U4 um das bewerkstelligen zu können.
Ein normaler ATmega328P braucht für sowas den V-USB Stack.
Thread beobachten
Seitenaufteilung abschalten