Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese

Benutzeravatar
Fritzler
Beiträge: 12597
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Meine Güte, nehmt euch nen Zimmer...
Bzw nen VReg mit Enable Eingang und nich son Pfusch da...
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Ich lösch's ja schon... :oops:
Profipruckel
Beiträge: 1506
Registriert: Di 13. Aug 2013, 19:10
Wohnort: Niedersachsen Süd-Ost

Re: Der AVR-/ARDUINO-Faden

Beitrag von Profipruckel »

Gernstel hat geschrieben:*grusel*
Wenn der AVR los lässt und der Taster nicht gedrückt wird, verliert der Spannungsregler sein 0-V-Bezugspotential und lässt nahezu die Eingangsspannung unstabilisiert auf den AVR los?
Auf welchen Schaltungsvorschlag beziehst Du diese Aussage?
Profipruckel
Beiträge: 1506
Registriert: Di 13. Aug 2013, 19:10
Wohnort: Niedersachsen Süd-Ost

Re: Der AVR-/ARDUINO-Faden

Beitrag von Profipruckel »

Fritzler hat geschrieben:Meine Güte, nehmt euch nen Zimmer...
Ich verstehe Dich! Ein (leider ehemaliger) Kollege sagte mal "Früher hat man sich für ein Problem eine Lösung erarbeitet, heute schreibt man erstmal ins Internet, dass man ein Problem hat"
Fritzler hat geschrieben:Bzw nen VReg mit Enable Eingang und nich son Pfusch da...
Der Herr (Name vergessen) hat in seinem Post vom 31. Jan 2016 auf die Schaltung vom Transistortester hingewiesen. Aus der Schaltung extrahiere ich:

Bild

Das ist zwar etwas Löterei, aber die Bauteile dafür hätte ich allesamt 'zigfach vorrätig, im Gegensatz zu einem abschaltbaren Regler.

Der T2 ist für das Spielzeugauto überflüssig, die LED besser auch. Der Taster "Test" kommt direkt auf Masse und heißt dann "Start". Direkt nach Hochlauf muß der Controller über R8 den T1 mit High versorgen, dann geht das doch.

Die Kür wäre, den T3 durch eine LogicLevel-MOS-Fet zu ersetzen, so man einen findet, der bei 3 Volt am Gate noch sicher offen ist.

Hast Du Einwände oder würdest auch Du erwarten, dass das so funktioniert?
Benutzeravatar
Fritzler
Beiträge: 12597
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

LED1 kann weg, ohne die kann der Taster Test aber kein zweites mal auslösen.
Also kein zweites mal messen oder lang drücken = ausschalten beim Transtester.
Aber T2 soll ja eh weg und es is kein Transtester.

Regler mit Enable habe ich wiederrum ne ganze Schublade voll im Aldi Sortimentskasten :twisted:
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Profipruckel hat geschrieben:Auf welchen Schaltungsvorschlag beziehst Du diese Aussage?
Das war auf meine Idee bezogen, einem 7805 mit einer Transe die Masse wegzuschalten (hatte ich aufgrund massiver Kritik gelöscht). Im Nachhinein bin ich mir zwar nicht sicher, ob das so nicht doch hinhauen hätte können (denn: alles, incl. AVR, hängt an der geschalteten Masse und nichts an der echten, somit gäbe es bei gesperrter Transe auch keinen Rückweg, alles hinge irgendwo bei 9v in der Luft), aber schön ist trotzdem anders. :)

@ Spannungsregler mit Enable: es ist klar, daß Ihr sowas habt, aber jemand, der nicht einmal einen BC558 sein Eigen nennt, wird wohl eher keinen haben. Da muß man schon etwas auf die individuelle Situation Rücksicht nehmen. Oder hattet Ihr ein vollausgestattetes Labor, als Ihr angefangen habt? :) OK, ich könnte jetzt den Tip geben, Autoradios zu schlachten, da scheinen gerne mal welche drin zu sein, aber dann in SMD...
Benutzeravatar
Münsterländer
Beiträge: 329
Registriert: Fr 11. Okt 2013, 14:55
Wohnort: Borken (bei Holland)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Münsterländer »

@ Profipruckel: Leider bin ich nicht in der Lage dazu, eigenständig eine Lösung für mein Problem zu erarbeiten, da ich nicht über die nötigen erfahrungen verfüge. Ich wollte das (fast) fertige Projekt halt noch verbessern. Manchmal gibt es ja auch billige standardlösungen, auf die man bisher nur noch nicht gestoßen ist.
Danke fürs extrahieren des Plans. Da brauche ich aber noch ne Menge Übung, wenn ich das halbwegs platzsparend aufbauen will. Ich halte es im Hinterkopf und werde es wenn ich mal richtig Zeit habe versuchen aufzubauen.
@ Name vergessen: Den Aufbau mit möglichst wenigen / gängigen Teilen zu bauen kommt mir sehr entgegen. Mein Lagerbestand ist im Moment noch sehr übersichtlich. Autoradio ist vielleicht sogar noch da, aber SMD ist eher nicht meine Kragenweite...
Jannyboy
Beiträge: 1412
Registriert: So 11. Aug 2013, 14:49
Wohnort: Kreis Augsburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Jannyboy »

Profipruckel hat geschrieben:
Fritzler hat geschrieben:Meine Güte, nehmt euch nen Zimmer...
Ich verstehe Dich! Ein (leider ehemaliger) Kollege sagte mal "Früher hat man sich für ein Problem eine Lösung erarbeitet, heute schreibt man erstmal ins Internet, dass man ein Problem hat"
Fritzler hat geschrieben:Bzw nen VReg mit Enable Eingang und nich son Pfusch da...
Der Herr (Name vergessen) hat in seinem Post vom 31. Jan 2016 auf die Schaltung vom Transistortester hingewiesen. Aus der Schaltung extrahiere ich:

Bild

Das ist zwar etwas Löterei, aber die Bauteile dafür hätte ich allesamt 'zigfach vorrätig, im Gegensatz zu einem abschaltbaren Regler.

Der T2 ist für das Spielzeugauto überflüssig, die LED besser auch. Der Taster "Test" kommt direkt auf Masse und heißt dann "Start". Direkt nach Hochlauf muß der Controller über R8 den T1 mit High versorgen, dann geht das doch.

Die Kür wäre, den T3 durch eine LogicLevel-MOS-Fet zu ersetzen, so man einen findet, der bei 3 Volt am Gate noch sicher offen ist.

Hast Du Einwände oder würdest auch Du erwarten, dass das so funktioniert?
Ansonsten kann man das auch mit einem MCP1702 lösen. Benötigt max. 2uA Ruhestrom + 1uA für den Controller mit Watchdog.
Das ist weniger als die Selbstentladung der Batterie.
Benutzeravatar
Daniel
Beiträge: 859
Registriert: Mi 14. Aug 2013, 21:43
Wohnort: NRW

Re: Der AVR-/ARDUINO-Faden

Beitrag von Daniel »

Hallo,
seid gestern habe ich einen Arduino 2560 aus China.
Den wollte ich aktivieren, es gelingt nicht.
Bekomme den Port nicht geändert usw.
Wie geht man vor wenn er neu aktiviert werden soll???

Danke und Gruß vom Daniel
Zuckermais
Beiträge: 71
Registriert: So 11. Aug 2013, 15:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Zuckermais »

Daniel hat geschrieben: Den wollte ich aktivieren, es gelingt nicht.
Sowas wie Produktaktivierung gibt es iirc beim Arduino und dessen Clones nicht.
Daniel hat geschrieben: Bekomme den Port nicht geändert usw.
Wie geht man vor wenn er neu aktiviert werden soll???
Was genau willst du erreichen?
Was hast du probiert?
Kompilliert der Sketch oder steigt er dabei schon aus?

Zuckermais
Benutzeravatar
Daniel
Beiträge: 859
Registriert: Mi 14. Aug 2013, 21:43
Wohnort: NRW

Re: Der AVR-/ARDUINO-Faden

Beitrag von Daniel »

Zuckermais hat geschrieben:
Daniel hat geschrieben: Den wollte ich aktivieren, es gelingt nicht.
Sowas wie Produktaktivierung gibt es iirc beim Arduino und dessen Clones nicht.
Daniel hat geschrieben: Bekomme den Port nicht geändert usw.
Wie geht man vor wenn er neu aktiviert werden soll???
Was genau willst du erreichen?
Was hast du probiert?
Kompilliert der Sketch oder steigt er dabei schon aus?

Zuckermais
Hallo,
kompilieren geht, aber den Fehler kann ich nicht deuten.
Originalsketch der im funzt I. Board permanent.
Zuletzt geändert von Daniel am So 7. Feb 2016, 15:09, insgesamt 1-mal geändert.
Profipruckel
Beiträge: 1506
Registriert: Di 13. Aug 2013, 19:10
Wohnort: Niedersachsen Süd-Ost

Re: Der AVR-/ARDUINO-Faden

Beitrag von Profipruckel »

Name vergessen hat geschrieben:@ Spannungsregler mit Enable: es ist klar, daß Ihr sowas habt, aber jemand, der nicht einmal einen BC558 sein Eigen nennt, wird wohl eher keinen haben.
Gut erkannt, ich habe weder BC558 noch schaltbare Spannungsregler da :-)

Der BC558 würde mir keine Sorgen machen, ich habe geeignete Transistoren mit anderer Hausnummer zur Hand. Von daher gefiel mir Dein Ansatz, die Abschaltung aus dem Transistortester abzukupfern - so würde ich das umsetzen!
Fritzler hat geschrieben:Regler mit Enable habe ich wiederrum ne ganze Schublade voll im Aldi Sortimentskasten
Sag' mal bitte Typennummern und, welchen Ruhestrom die nehmen. Es gibt einen im Arduino-Mini, aber dessen Ruhestrom wäre mir für eine 9V-Batterie noch unfreundlich hoch.
Jannyboy hat geschrieben:Ansonsten kann man das auch mit einem MCP1702 lösen. Benötigt max. 2uA Ruhestrom + 1uA für den Controller mit Watchdog.
Leider an der Problemstellung vorbei: Der MCP1702 macht Sinn, weil er selbst wenig Strom zieht. Die 2µA sind aber "typisch", am realen Bauteil dürfen es ein paar mehr sein und sind es auch, wobei die "max 5 µA" gemäß Datenblatt auch nicht wirklich weh tun.

Münsterländer setzt einen Arduino ein, in seinem Bild einen UNO. Samt seiner Peripherie (USB, 3,3V-Regler) bekommst Du den UNO nicht unter ca. 30..50 mA, selbst, wenn der AT328 schläft. Du gehst von einem blanken AVR aus, wobei ich auch zu dem noch 80 µA im Schlafmodus finde.

Ich sehe den Vorschlag mit Transistor vor dem Regler als optimale Lösung, da gibt es keinen messbaren Ruhestrom mehr, der wird irgendwo bei nA liegen.
Benutzeravatar
xoexlepox
Beiträge: 4815
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

Wer sich sowohl mit dem RasPi, als auch mit AVRs beschäftigt (oder beschäftigen möchte), dem sei die Lektüre des Artikels "Programmierung von AVR-Controllern mit dem Raspberry Pi" von DL6PH in der aktuellen Ausgabe (2/2016) der Zeitschrift "Funkamateur" empfohlen: Eine nette Anleitung, wie man mit Hilfe eines RasPi (unter Raspbian) C-Programme für AVRs erzeugt, und sie mit Hilfe einer kleinen Schaltung in den Chip schafft.
Benutzeravatar
Fritzler
Beiträge: 12597
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Es braucht ja nichtmal ne kleine Schaltung um das AVR Programm vom PI in den AVR zu bekommen.
https://www.mikrocontroller.net/article ... programmer

avrdude hat nen Plugin für Linux SPI, was der RasPI ja hat :D

Is da ne Zeitschrift mal wieder am Internet ausdrucken?
Benutzeravatar
xoexlepox
Beiträge: 4815
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

Fritzler hat geschrieben:Is da ne Zeitschrift mal wieder am Internet ausdrucken?
Glaube ich weniger, da die verwendeten GPIO-Pins andere sind, und zur Progammübertragung Phyton-Scripte Verwendung finden. Die "Adapterschaltung" ist im Prinzip ein Pegelwandler. Der Author scheint mir auch nicht gerade ein "Linux-Freak" zu sein, aber er erklärt sehr schön (und "anfängergeeignet") welche Pakete benötigt werden, und wie sie zu installieren/konfigurieren sind. Das ist vermutlich auch nicht der optimale/einfachste Weg, der beschrieben wird -> Sieht sehr "selbst erarbeitet" aus.
Benutzeravatar
Daniel
Beiträge: 859
Registriert: Mi 14. Aug 2013, 21:43
Wohnort: NRW

Re: Der AVR-/ARDUINO-Faden

Beitrag von Daniel »

Daniel hat geschrieben:
Zuckermais hat geschrieben:
Daniel hat geschrieben: Den wollte ich aktivieren, es gelingt nicht.
Sowas wie Produktaktivierung gibt es iirc beim Arduino und dessen Clones nicht.
Daniel hat geschrieben: Bekomme den Port nicht geändert usw.
Wie geht man vor wenn er neu aktiviert werden soll???
Was genau willst du erreichen?
Was hast du probiert?
Kompilliert der Sketch oder steigt er dabei schon aus?

Zuckermais
Hallo,
kompilieren geht, aber den Fehler kann ich nicht deuten.
Originalsketch der im funzt I. Board von 2015 permanent.
Mir geht es auch darum, ob ich die Teile wieder retournieren soll.
Die Test LED und an Pin 13 blinken externe LED wie es nach dem Anlegen der Betriebsspannung sein soll.
Was mache ich verkehrt???
Benutzeravatar
xoexlepox
Beiträge: 4815
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

Daniel hat geschrieben:Die Test LED und an Pin 13 blinken externe LED wie es nach dem Anlegen der Betriebsspannung sein soll.
Was mache ich verkehrt???
Um das zu beurteilen, wäre es notwendig zu wissen, wo und wie du deine "nichtleuchtende" LED an das Teil angebunden hast, und was für eine LED du verwendest -> z.B. eine weisse 1W-LED wird nicht unbedingt funktionieren.
Benutzeravatar
Daniel
Beiträge: 859
Registriert: Mi 14. Aug 2013, 21:43
Wohnort: NRW

Re: Der AVR-/ARDUINO-Faden

Beitrag von Daniel »

xoexlepox hat geschrieben:
Daniel hat geschrieben:Die Test LED und an Pin 13 blinken externe LED wie es nach dem Anlegen der Betriebsspannung sein soll.
Was mache ich verkehrt???
Um das zu beurteilen, wäre es notwendig zu wissen, wo und wie du deine "nichtleuchtende" LED an das Teil angebunden hast, und was für eine LED du verwendest -> z.B. eine weisse 1W-LED wird nicht unbedingt funktionieren.
Sorry, die Test LED auf dem Board blinkt.
Wenn ich eine extern LED an Pin 13 und GND stecke, blinkt diese auch.
Für mich ein Zeichen, die Boards sind i.O. auf den ersten Blick.
Nur gelingt es mir nicht ein auf meinem bisherigen Board laufende Sketche in den neuen zu aktivieren. Kompilieren geht, aber dann ist Sense.

Danke und Gruß vom Daniel
Benutzeravatar
xoexlepox
Beiträge: 4815
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

Daniel hat geschrieben:Nur gelingt es mir nicht ein auf meinem bisherigen Board laufende Sketche in den neuen zu aktivieren. Kompilieren geht, aber dann ist Sense.
Ok, dann scheint es so zu sein, das du das fertige Hexfile nicht auf das Board bekommst. Wie/womit versuchst du das? Avrdude? Gibt es irgendwelche Fehlermeldungen? Ich nehme mal an, das USB-Kabel und der Port sind ok?
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Hatte er nicht das komplette Log gepostet? Aber ich seh's nicht mehr... habe ich das nur geträumt? :shock: Stand irgendwas drin von wegen ID nicht erkannt und veraltete Files und Device not found (COM irgendwas)...
margau
Beiträge: 78
Registriert: Sa 7. Nov 2015, 23:15
Wohnort: Rhein-Main

Re: Der AVR-/ARDUINO-Faden

Beitrag von margau »

Ich gehe mal von Arduino IDE aus.
Ist das richtige Board ausgewählt?
Der richtige COM-Port?
Sagt der Geräte manager was zum Com-Port?

Viele Grüße!
margau
Benutzeravatar
Daniel
Beiträge: 859
Registriert: Mi 14. Aug 2013, 21:43
Wohnort: NRW

Re: Der AVR-/ARDUINO-Faden

Beitrag von Daniel »

Daniel hat geschrieben:
Daniel hat geschrieben:
Zuckermais hat geschrieben:
Daniel hat geschrieben: Den wollte ich aktivieren, es gelingt nicht.
Sowas wie Produktaktivierung gibt es iirc beim Arduino und dessen Clones nicht.
Daniel hat geschrieben: Bekomme den Port nicht geändert usw.
Wie geht man vor wenn er neu aktiviert werden soll???
Was genau willst du erreichen?
Was hast du probiert?
Kompilliert der Sketch oder steigt er dabei schon aus?

Zuckermais
Hallo,
kompilieren geht, aber den Fehler kann ich nicht deuten.
Originalsketch der im funzt I. Board von 2015 permanent.
Mir geht es auch darum, ob ich die Teile wieder retournieren soll.
Die Test LED und an Pin 13 blinken externe LED wie es nach dem Anlegen der Betriebsspannung sein soll.
Was mache ich verkehrt???


Hallo,
ich habe diesen einfachen Wechselblinker gersteckt.

Dieser Sketch.
void loop()

{

digitalWrite(7, HIGH);

delay(1000);

digitalWrite(7, LOW);

digitalWrite(8, HIGH);

delay(1000);

digitalWrite(8, LOW);

}


Nach dem Kompilieren:
Arduino: 1.6.6 (Windows 7), Board: "Arduino Uno"

Warnung: platform.txt aus dem Kern 'Arduino AVR Boards' enthält veraltete recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{build.path}/{archive_file}" "{object_file}" und wurde automatisch zu recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{archive_file_path}" "{object_file}" konvertiert. Erwägen Sie eine Aktualisierung dieses Kerns.
WARNUNG: Kategorie '' in der Bibliothek EEPROM ist ungültig und wird auf 'Uncategorized' festgelegt
WARNUNG: Kategorie '' in der Bibliothek SPI ist ungültig und wird auf 'Uncategorized' festgelegt
WARNUNG: Kategorie '' in der Bibliothek SoftwareSerial ist ungültig und wird auf 'Uncategorized' festgelegt
WARNUNG: Kategorie '' in der Bibliothek Wire ist ungültig und wird auf 'Uncategorized' festgelegt
Build-Optionen wurden verändert, alles wird neu kompiliert

Der Sketch verwendet 1.054 Bytes (3%) des Programmspeicherplatzes. Das Maximum sind 32.256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers, 2.039 Bytes für lokale Variablen verbleiben. Das Maximum sind 2.048 Bytes.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x8d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x8d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x8d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x8d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x8d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x8d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x8d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x8d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x8d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x8d
Problem beim Hochladen auf das Board. Hilfestellung dazu unter http://www.arduino.cc/en/Guide/Troubleshooting#upload.
Ungültige Bibliothek C:\Users\quinta\Documents\Arduino\libraries\Bridge in C:\Users\quinta\Documents\Arduino\libraries\Bridge gefunden
Ungültige Bibliothek C:\Users\quinta\Documents\Arduino\libraries\Bridge in C:\Users\quinta\Documents\Arduino\libraries\Bridge gefunden

Dieser Report hätte mehr Informationen mit
"Ausführliche Ausgabe während der Kompilierung"
aktiviert in Datei > Einstellungen.
Auch gelingt es mir nicht den Port zu ändern.

Danke
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Ah, da ist es ja wieder! OoooK... das klingt sehr danach, daß der Bootloader nicht mit dem von der IDE Erwarteten zusammenpaßt (Du hast da einen Bootloader drin, korrekt?). Genau den Effekt hatte ich nämlich auch mit meinem Duemilanove. Der mochte sich einfach nicht als solcher ansprechen lassen, ich mußte Uno oder sowas nehmen (im AVRdude "arduino"). Deine Befehlszeile versucht, das Ding als STK500 anzusprechen (es gibt Bootloader, für die das korrekt ist). Das STK500 ist aber ein RS232-Gerät (obwohl es dabei hauptsächlich um das Protokoll geht, kann das ggfs. auch die Port-Einstellung beeinflussen, und die kannst Du ja z.Zt. nicht ändern, oder meinst Du einen Port im AVR-Code? Da Dein Rechner maximal einen RS232-Port haben dürfte, schießt die IDE sich auf den ein; aber auch, wenn Du mehrere hättest, würde davon keiner stimmen).
Der Uno montiert sich aber als USB-Gerät (zumindest unter Linux). Somit müßtest Du mal mit den verschiedenen Board-Varianten spielen und gucken, wann da nicht mehr"STK500" sondern "arduino" steht. Ich beschreibe meinen mit

Code: Alles auswählen

avrdude -C /usr/share/arduino/hardware/tools/avrdude.conf -P /dev/ttyUSB0 -c arduino -p atmega8 -b19200 -D -Uflash:w:$1:i
Das liegt daran, daß ich zwar das Duemilanove-Board benute, aber einen Atmega8 hineingesteckt habe. Ich glaube (ist schon etwas her), daß ich da den Uno-Bootloader reingeflasht habe; ich habe seinerzeit geguckt, daß der sowohl FT232 als auch Mega8 drauf hat, das war IIRC der Uno.

Zu guter Letzt könnte es aber auch noch sein, daß Dir der notwendige Treiber fehlt, damit sich der USB/RS232-Umsetzerchip überhaupt als Gerät anmelden kann. Und falls Du Pech hast, und das ein Fake ist (was Du nicht erkennen kannst), dann möchte der FTDI-Treiber den nicht, oder hat ihn ggfs. gebrickt.
Zuletzt geändert von Name vergessen am Di 9. Feb 2016, 21:18, insgesamt 1-mal geändert.
Benutzeravatar
Münsterländer
Beiträge: 329
Registriert: Fr 11. Okt 2013, 14:55
Wohnort: Borken (bei Holland)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Münsterländer »

Hallo Daniel!
Ich bin ja Anfänger, vielleicht ist der Ansatz bei deinem Arduino völliger Humbug, aber da sonst noch keiner antwortet hier eine Idee:
Bei meinem Pro Mini (der allerdiungs auch über TTL Adapter und nicht direkt über USB angesprochen wird) ist es nötig ihn zwischendurch zu reseten. Ich halte den Restknopf gedrückt, bis das Kompilieren beendet ist. Dann loslassen und alles wird gut. Das sollte sich ja auf jeden Fall problemlos austesten lassen.
Gruß aus dem Münsterland,
Thomas
Edit sagt, dass das ja auch in deinem Link beschrieben ist.
lange5766
Beiträge: 33
Registriert: So 11. Aug 2013, 15:51

Re: Der AVR-/ARDUINO-Faden

Beitrag von lange5766 »

Daniel hat geschrieben:Hallo,
seid gestern habe ich einen Arduino 2560 aus China.
Den wollte ich aktivieren, es gelingt nicht.
Bekomme den Port nicht geändert usw.
Wie geht man vor wenn er neu aktiviert werden soll???

Danke und Gruß vom Daniel

Hi,

Ich würde sagen der "Arduino 2560 aus China" wird wohl ein günstiger Arduino Mega Clone sein
mit CH340-Chip als USB zu seriell-Umsetzer.

Wenn ein CH340 auf dem Board ist muss zumindest unter Windows der passende Treiber installiert werden.
Siehe http://www.jens-bretschneider.de/aktuel ... b-adapter/

Nach der Installation sollte bei angesteckten Arduino im Gerätemanager ein neuer COM-Port auftauchen,
dann in der Arduino-IDE den gefundenen Port und als Board "Arduino Mega or Mega 2560 einstellen.

Gruß: Marco (lange5766)
Benutzeravatar
Daniel
Beiträge: 859
Registriert: Mi 14. Aug 2013, 21:43
Wohnort: NRW

Re: Der AVR-/ARDUINO-Faden

Beitrag von Daniel »

lange5766 hat geschrieben:
Daniel hat geschrieben:Hallo,
seid gestern habe ich einen Arduino 2560 aus China.
Den wollte ich aktivieren, es gelingt nicht.
Bekomme den Port nicht geändert usw.
Wie geht man vor wenn er neu aktiviert werden soll???

Danke und Gruß vom Daniel

Hi,

Ich würde sagen der "Arduino 2560 aus China" wird wohl ein günstiger Arduino Mega Clone sein
mit CH340-Chip als USB zu seriell-Umsetzer.

Wenn ein CH340 auf dem Board ist muss zumindest unter Windows der passende Treiber installiert werden.
Siehe http://www.jens-bretschneider.de/aktuel ... b-adapter/

Nach der Installation sollte bei angesteckten Arduino im Gerätemanager ein neuer COM-Port auftauchen,
dann in der Arduino-IDE den gefundenen Port und als Board "Arduino Mega or Mega 2560 einstellen.

Gruß: Marco (lange5766)
Hallo und danke,

nach ich den China Treiber installierte, laufen beide Clone.
Gruß Daniel
Benutzeravatar
erwin
Beiträge: 710
Registriert: Do 15. Aug 2013, 08:57
Wohnort: 68642 Bürstadt
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von erwin »

Hallo ich bekomme diesen
/**
Polargraph Server for Arduino UNO and MEGA compatible boards.
Written by Sandy Noble
Released under GNU License version 3.
http://www.polargraph.co.uk
https://github.com/euphy/polargraph_server_a1


CONFIGURATION!! Read this! Really.
==================================

Kung fu is like a game of chess. You must think first! Before you move.

This is a unified codebase for a few different versions of Polargraph Server.

You can control how it is compiled by changing the #define lines below.

There are five config sections:
1. Specify what kind of controller board you are using
2. Add some libraries if you have a MEGA
3. Specify what kind of motor driver you are using:
i. Adafruit Motorshield v1
ii. Adafruit Motorshield v2
iii. Discrete stepper drivers (eg EasyDriver, stepstick, Pololu gear).*
iv. Signal amplifier like a UNL2003*
4. Turn on some debugging code
5. Disable program features if you need to free up space

For motor drivers iii and iv, you will need to change the values in
configuration.ino to set the exact pins the drivers are wired up to.

*/


// 1. Specify what kind of controller board you are using
// ======================================================
// UNO or MEGA. Uncomment the line for the kind of board you have.
#ifndef MICROCONTROLLER
#define MICROCONTROLLER MC_UNO

#endif


// 2. Add some libraries if you have a MEGA
// ========================================
// Uncomment the SPI and SD lines below if you have a MEGA.
// http://forum.arduino.cc/index.php?topic=173584.0
//#include <SPI.h>
//#include <SD.h>


// 3. Specify what kind of motor driver you are using
// ==================================================
// Only ONE set of lines below should be uncommented.

// i. Adafruit Motorshield v1. The original, and still the best.
// -------------------------------------------------------------
#define ADAFRUIT_MOTORSHIELD_V1


// ii. Adafruit Motorshield v2. It's all squealy.
// ----------------------------------------------
//#define ADAFRUIT_MOTORSHIELD_V2
//#include <Wire.h>
//#include <Adafruit_MotorShield.h>
//#include "utility/Adafruit_PWMServoDriver.h"

// iii. Using discrete stepper drivers? (eg EasyDriver, stepstick, Pololu gear)
// ----------------------------------------------------------------------------
// Don't forget to define your pins in 'configuration.ino'.
//#define SERIAL_STEPPER_DRIVERS

// iv. Using a signal amplifier like a UNL2003?
// --------------------------------------------
// Don't forget to define your pins in 'configuration.ino'.
// #define UNL2003_DRIVER


// 4. Turn on some debugging code if you want horror
// =================================================
//#define DEBUG
//#define DEBUG_COMMS
//#define DEBUG_PENLIFT
//#define DEBUG_PIXEL


// 5. Disable program features if you need to free up space
// ===================================================



/* ===========================================================
These variables are common to all polargraph server builds
=========================================================== */

// ==========================================================
// Some microcontroller's names
#define MC_UNO 1
#define MC_MEGA 2

#include <AccelStepper.h>
#include <Servo.h>
#include <EEPROM.h>
#include "EEPROMAnything.h"

const String FIRMWARE_VERSION_NO = "1.2.1";

// EEPROM addresses
const byte EEPROM_MACHINE_WIDTH = 0;
const byte EEPROM_MACHINE_HEIGHT = 2;
const byte EEPROM_MACHINE_MM_PER_REV = 14; // 4 bytes (float)
const byte EEPROM_MACHINE_STEPS_PER_REV = 18;
const byte EEPROM_MACHINE_STEP_MULTIPLIER = 20;

const byte EEPROM_MACHINE_MOTOR_SPEED = 22; // 4 bytes float
const byte EEPROM_MACHINE_MOTOR_ACCEL = 26; // 4 bytes float
const byte EEPROM_MACHINE_PEN_WIDTH = 30; // 4 bytes float

const byte EEPROM_MACHINE_HOME_A = 34; // 4 bytes
const byte EEPROM_MACHINE_HOME_B = 38; // 4 bytes

const byte EEPROM_PENLIFT_DOWN = 42; // 2 bytes
const byte EEPROM_PENLIFT_UP = 44; // 2 bytes

// Pen raising servo
Servo penHeight;
const int DEFAULT_DOWN_POSITION = 90;
const int DEFAULT_UP_POSITION = 180;
static int upPosition = DEFAULT_UP_POSITION; // defaults
static int downPosition = DEFAULT_DOWN_POSITION;
static int penLiftSpeed = 3; // ms between steps of moving motor
const byte PEN_HEIGHT_SERVO_PIN = 9; //UNL2003 driver uses pin 9
boolean isPenUp = false;

// Machine specification defaults
const int DEFAULT_MACHINE_WIDTH = 650;
const int DEFAULT_MACHINE_HEIGHT = 650;
const int DEFAULT_MM_PER_REV = 95;
const int DEFAULT_STEPS_PER_REV = 400;
const int DEFAULT_STEP_MULTIPLIER = 1;

// working machine specification
static int motorStepsPerRev = DEFAULT_STEPS_PER_REV;
static float mmPerRev = DEFAULT_MM_PER_REV;
static byte stepMultiplier = DEFAULT_STEP_MULTIPLIER;
static int machineWidth = DEFAULT_MACHINE_WIDTH;
static int machineHeight = DEFAULT_MACHINE_HEIGHT;


static float currentMaxSpeed = 800.0;
static float currentAcceleration = 400.0;
static boolean usingAcceleration = true;

int startLengthMM = 800;

float mmPerStep = 0.0F;
float stepsPerMM = 0.0F;

long pageWidth = machineWidth * stepsPerMM;
long pageHeight = machineHeight * stepsPerMM;
long maxLength = 0;

//static char rowAxis = 'A';
const int INLENGTH = 50;
const char INTERMINATOR = 10;
const char SEMICOLON = ';';

float penWidth = 0.8F; // line width in mm

boolean reportingPosition = true;
boolean acceleration = true;

extern AccelStepper motorA;
extern AccelStepper motorB;

boolean currentlyRunning = true;

static char inCmd[10];
static char inParam1[14];
static char inParam2[14];
static char inParam3[14];
static char inParam4[14];

static byte inNoOfParams;

char lastCommand[INLENGTH + 1];
boolean commandConfirmed = false;

int rebroadcastReadyInterval = 5000;
long lastOperationTime = 0L;
long motorIdleTimeBeforePowerDown = 600000L;
boolean automaticPowerDown = true;
boolean powerIsOn = false;

long lastInteractionTime = 0L;

#ifdef PIXEL_DRAWING
static boolean lastWaveWasTop = true;

// Drawing direction
const static byte DIR_NE = 1;
const static byte DIR_SE = 2;
const static byte DIR_SW = 3;
const static byte DIR_NW = 4;

static int globalDrawDirection = DIR_NW;

const static byte DIR_MODE_AUTO = 1;
const static byte DIR_MODE_PRESET = 2;
static byte globalDrawDirectionMode = DIR_MODE_AUTO;
#endif

#if MICROCONTROLLER == MC_MEGA
#define READY_STR "READY_100"
#else
#define READY_STR "READY"
#endif

#define RESEND_STR "RESEND"
#define DRAWING_STR "DRAWING"
#define OUT_CMD_SYNC_STR "SYNC,"

char MSG_E_STR[] = "MSG,E,";
char MSG_I_STR[] = "MSG,I,";
char MSG_D_STR[] = "MSG,D,";

const static char COMMA[] = ",";
const static char CMD_END[] = ",END";
const static String CMD_CHANGELENGTH = "C01";
const static String CMD_CHANGEPENWIDTH = "C02";
#ifdef PIXEL_DRAWING
const static String CMD_DRAWPIXEL = "C05";
const static String CMD_DRAWSCRIBBLEPIXEL = "C06";
const static String CMD_CHANGEDRAWINGDIRECTION = "C08";
const static String CMD_TESTPENWIDTHSQUARE = "C11";
#endif
const static String CMD_SETPOSITION = "C09";
#ifdef PENLIFT
const static String CMD_PENDOWN = "C13";
const static String CMD_PENUP = "C14";
const static String CMD_SETPENLIFTRANGE = "C45";
#endif
#ifdef VECTOR_LINES
const static String CMD_CHANGELENGTHDIRECT = "C17";
#endif
const static String CMD_SETMACHINESIZE = "C24";
const static String CMD_GETMACHINEDETAILS = "C26";
const static String CMD_RESETEEPROM = "C27";
const static String CMD_SETMACHINEMMPERREV = "C29";
const static String CMD_SETMACHINESTEPSPERREV = "C30";
const static String CMD_SETMOTORSPEED = "C31";
const static String CMD_SETMOTORACCEL = "C32";
const static String CMD_SETMACHINESTEPMULTIPLIER = "C37";

void setup()
{
Serial.begin(57600); // set up Serial library at 57600 bps
Serial.println("POLARGRAPH ON!");
Serial.print("Hardware: ");
Serial.println(MICROCONTROLLER);

#if MICROCONTROLLER == MC_MEGA
Serial.println("MC_MEGA");
#elif MICROCONTROLLER == MC_UNO
Serial.println("MC_UNO");
#else
Serial.println("No MC");
#endif
configuration_motorSetup();
eeprom_loadMachineSpecFromEeprom();
configuration_setup();

motorA.setMaxSpeed(currentMaxSpeed);
motorA.setAcceleration(currentAcceleration);
motorB.setMaxSpeed(currentMaxSpeed);
motorB.setAcceleration(currentAcceleration);

float startLength = ((float) startLengthMM / (float) mmPerRev) * (float) motorStepsPerRev;
motorA.setCurrentPosition(startLength);
motorB.setCurrentPosition(startLength);
for (int i = 0; i < INLENGTH; i++) {
lastCommand = 0;
}
comms_ready();

#ifdef PENLIFT
penlift_penUp();
#endif
delay(500);

}

void loop()
{
if (comms_waitForNextCommand(lastCommand))
{
#ifdef DEBUG_COMMS
Serial.print(F("Last comm: "));
Serial.print(lastCommand);
Serial.println(F("..."));
#endif
comms_parseAndExecuteCommand(lastCommand);
}
}

#if MICROCONTROLLER == MC_MEGA
const static String CMD_TESTPENWIDTHSCRIBBLE = "C12";
const static String CMD_DRAWSAWPIXEL = "C15,";
const static String CMD_DRAWCIRCLEPIXEL = "C16";
const static String CMD_SET_ROVE_AREA = "C21";
const static String CMD_DRAWDIRECTIONTEST = "C28";
const static String CMD_MODE_STORE_COMMANDS = "C33";
const static String CMD_MODE_EXEC_FROM_STORE = "C34";
const static String CMD_MODE_LIVE = "C35";
const static String CMD_RANDOM_DRAW = "C36";
const static String CMD_START_TEXT = "C38";
const static String CMD_DRAW_SPRITE = "C39";
const static String CMD_CHANGELENGTH_RELATIVE = "C40";
const static String CMD_SWIRLING = "C41";
const static String CMD_DRAW_RANDOM_SPRITE = "C42";
const static String CMD_DRAW_NORWEGIAN = "C43";
const static String CMD_DRAW_NORWEGIAN_OUTLINE = "C44";

/* End stop pin definitions */
const int ENDSTOP_X_MAX = 17;
const int ENDSTOP_X_MIN = 16;
const int ENDSTOP_Y_MAX = 15;
const int ENDSTOP_Y_MIN = 14;

long ENDSTOP_X_MIN_POSITION = 130;
long
ENDSTOP_Y_MIN_POSITION = 130;

// size and location of rove area
long rove1x = 1000;
long rove1y = 1000;
long roveWidth = 5000;
long roveHeight = 8000;

boolean swirling = false;
String spritePrefix = "";
int textRowSize = 200;
int textCharSize = 180;

boolean useRoveArea = false;

int commandNo = 0;
int errorInjection = 0;

boolean storeCommands = false;
boolean drawFromStore = false;
String commandFilename = "";

// sd card stuff
const int chipSelect = 53;
boolean sdCardInit = false;

// set up variables using the SD utility library functions:
File root;
boolean cardPresent = false;
boolean cardInit = false;
boolean echoingStoredCommands = false;

// the file itself
File pbmFile;

// information we extract about the bitmap file
long pbmWidth, pbmHeight;
float pbmScaling = 1.0;
int pbmDepth, pbmImageoffset;
long pbmFileLength = 0;
float pbmAspectRatio = 1.0;

volatile int speedChangeIncrement = 100;
volatile int accelChangeIncrement = 100;
volatile float penWidthIncrement = 0.05;
volatile int moveIncrement = 400;

boolean currentlyDrawingFromFile = false;
String currentlyDrawingFilename = "";

static float translateX = 0.0;
static float translateY = 0.0;
static float scaleX = 1.0;
static float scaleY = 1.0;
static int rotateTransform = 0;

#endif


Sketch nicht zum laufen habe für mich unlösbare Fehlermeldungen schon beim kompilieren .Er befindet sich hier https://github.com/euphy/polargrap ... 1-26-23-24
es sollten zwei Schritt motoren mit zweihundert schritten und ein servo mit einem Motor Shield v2.0 angesteuert werden
Benutzeravatar
Bauteiltöter
Beiträge: 254
Registriert: So 11. Aug 2013, 17:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bauteiltöter »

Wie wäre es wenn du diese "unlösbaren Fehlermeldungen" postest? Das wäre deutlich Sinnvoller als den Code hier rein zu kopieren... und dann auch noch ohne Code-Tags. Der Link zu Github ist übrigens 404. So können wir dir nicht helfen.
Benutzeravatar
gafu
Beiträge: 6388
Registriert: Mi 14. Aug 2013, 20:56
Wohnort: nahe Jena
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von gafu »

Name vergessen hat geschrieben:Deine Befehlszeile versucht, das Ding als STK500 anzusprechen (es gibt Bootloader, für die das korrekt ist). Das STK500 ist aber ein RS232-Gerät (obwohl es dabei hauptsächlich um das Protokoll geht, kann das ggfs. auch die Port-Einstellung beeinflussen, und die kannst Du ja z.Zt. nicht ändern, oder meinst Du einen Port im AVR-Code? Da Dein Rechner maximal einen RS232-Port haben dürfte, schießt die IDE sich auf den ein; aber auch, wenn Du mehrere hättest, würde davon keiner stimmen).
Der Uno montiert sich aber als USB-Gerät (zumindest unter Linux).
Hier war offensichtlich doch windoof gefragt.. aber trotzdem der vollständigkeit halber:
Es gibt die boards mit verschiedenen seriell-usb-adaptern.
original ist ein quadratischer "MEGA16U2" drauf.
Der spricht USB und hat seine eigene firmware und meldet sich als usb-device an.

Viele der Clones haben aber jetzt stino-USB-Seriell-Chips drauf, was auch nix macht. Treiber sind unter linux für alle gängigen devices im Kernel enthalten, unter windoof muss man halt suchen ob der serielle port auftaucht.

Ist der USb-Ser-Port da, (gerätemanager bei windoof), den im Arduino IDE auswählen. Nicht vergessen das richtige Arduino-board auszuwählen, sonst gibts viele fehler...

Unter linux das gerät anstecken (USB) und dann einfach mal mit "dmesg" die letzten kernelmeldungen ansehen. Da sollte in den letzten Zeilen das usb-gerät als /dev/ttyACM0 oder sowas aufgelistet sein.

Dann das arduino-IDE von der konsole mit root-rechten starten, oder mit chmod der "datei" /dev/ttyACM0 zugriffsrechte (schreiben auch!) für "alle" verpassen, und den eigenen user der gruppe "dialout" hinzufügen (für rechte für serielle kommunikation).

Sonst geht unter linux kein zugriff von der IDE auf das Gerät, weil die Rechte nicht vorhanden sind.
Benutzeravatar
gafu
Beiträge: 6388
Registriert: Mi 14. Aug 2013, 20:56
Wohnort: nahe Jena
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von gafu »

@erwin: Code bitte immer mit dem Code-Tag einbinden.
Eerstens wird dann im Forum nicht Code zu smileys konvertiert und damit kaputt gemacht, und zweitens bekommt er nen feld mit scrollbalken und macht die lesbarkeit des Thread hier nicht kaputt.

@Bauteiltöter: Der richtige link steht oben im Code.
Benutzeravatar
xoexlepox
Beiträge: 4815
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

gafu hat geschrieben:Unter linux das gerät anstecken (USB) und dann einfach mal mit "dmesg" die letzten kernelmeldungen ansehen.
Das geht mit "dmesg"? Ich verwende immer "tail -f /var/log/messages", das zeigt dann kontinuierlich an (bis du es mit "ctrl-C" abbrichst). Mag sein, das manche Distributionen dafür Rootreche (oder ein "sudo " davor) haben wollen.
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Jo, dmesg nehme ich auch immer. Tippt sich schneller und scrollt nicht weiter (naja, so viel scrollt da ja nicht), und man braucht auch kein STRG-C, bevor man weitertippen kann.
gafu hat geschrieben:Dann das arduino-IDE von der konsole mit root-rechten starten, oder mit chmod der "datei" /dev/ttyACM0 zugriffsrechte (schreiben auch!) für "alle" verpassen, und den eigenen user der gruppe "dialout" hinzufügen (für rechte für serielle kommunikation).
Eschd, man braucht beides? Ich hätte jetzt erwartet, daß das mit Lese+Schreibrechten für jeden gegessen sei, bzw. hätte das wohl nur in dialout o.Ä. gepackt.
Benutzeravatar
gafu
Beiträge: 6388
Registriert: Mi 14. Aug 2013, 20:56
Wohnort: nahe Jena
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von gafu »

ob man beides braucht weiß ich auch nicht mit sicherheit, nur das adduser --addgroup nicht ausreicht.
Das blöde ist ja, das die vergebenen rechte auf dem usb-seriell-device bei jedem abstecken wieder verloren gehen, und man erst wieder in den linux-eingeweiden herumfummeln muss um eine ausnahme zu konfigurieren.

Da ist es echt einfacher, wenn man das nur alle jubeljahre mal braucht, die arduino-ide als root zu starten und das programmchen als root auf die hardware draufzubrezeln.

Das gleiche gilt leider auch für AVRDUDE mit dem usbasp, und natürlich für tty-usb-devices von 3d-druckern unter linux.
Wenn man den drucker aber regelmäßig braucht, dann kann man sich ja ein shellscript machen (mit gksu drinn) zum starten vom Programm, und den chmod-befehl vor dem programmstart automatisiert ausführen.
margau
Beiträge: 78
Registriert: Sa 7. Nov 2015, 23:15
Wohnort: Rhein-Main

Re: Der AVR-/ARDUINO-Faden

Beitrag von margau »

Also zumindest die usbasp-Sache hatte ich gestern auch, da gibt es einen sehr einfachem Workaround. Einfach mal nach "usbasp Linux arduino" oder so googeln, da hatte ich was gefunden. Meine UNOs hab ich auch mit 2 Befehlen zum laufen bekommen.

Viele Grüße!
margau
Benutzeravatar
Heaterman
Beiträge: 3990
Registriert: Fr 28. Jun 2013, 10:11
Wohnort: Am Rand der Scheibe, 6 m unter NN

Re: Der AVR-/ARDUINO-Faden

Beitrag von Heaterman »

Trotz etwas Skepsis beim Chinamann eine Charge Nanos (328) mit CH-340 gekauft. Funktioniert mit dem Win 7-CH-341-Treiber einwandfrei und geht nahtlos in der IDE. Für knapp 2 Euro pro Stück und dazu ESP8266 (2,5 €) sehr schönes Teil für Funk-Sensoren.
Profipruckel
Beiträge: 1506
Registriert: Di 13. Aug 2013, 19:10
Wohnort: Niedersachsen Süd-Ost

Re: Der AVR-/ARDUINO-Faden

Beitrag von Profipruckel »

Heaterman hat geschrieben:Trotz etwas Skepsis beim Chinamann eine Charge Nanos (328) mit CH-340 gekauft. Funktioniert mit dem Win 7-CH-341-Treiber einwandfrei und geht nahtlos in der IDE. Für knapp 2 Euro pro Stück und dazu ESP8266 (2,5 €) sehr schönes Teil für Funk-Sensoren.
Kann ich bestätigen!

Ich hatte letzten Sommer eine Idee, die rein analog nicht lösbar ist. Mit digitaler Hardware mochte ich nicht anfangen, unbekannte Parameter - also vom Ali zwei UNOs geordert, in Summe 5,58 € incl Kartengebühren.

Nach etwas Sucherei den CH341-Treiber gefunden, spielte klaglos. Quer über diverse Foren finden sich diverse Leute, die zu dusselig sind, den CH341-Treiber zu finden bzw. zu installieren - für die ist das Original vermutlich besser, das soll Windows angeblich per WinUpdate selbst holen.

Da ich den UNO mechanisch dämlich finde, erstmal zwei Nanos gekauft und bespielt, später weitere - zwischen 1,95 und 2,99 U$D. Hier gab es einen Ausrutscher, zwei von drei gelieferten spielten nicht. Gab etwas Diskussion mit dem Dispute beim Ali, aber wurde erstattet. Inzwischen weiß ich, dass auf den zwei ChinNanos der Bootloader fehlte - aber, wenn ich Hardware habe, den flashen zu können, brauche ich eigentlich keinen Arduino mehr.

Ganz nett finde ich die Adapterplatinen, wenn man mal einen fliegenden Testaufbau machen muss.

Für den einen oder anderen Einsteiger hier könnte das aktuelle Sonderheft von Heise interessant sein: 24,95 Euro versandkostenfrei incl. einem UNO.
Benutzeravatar
Heaterman
Beiträge: 3990
Registriert: Fr 28. Jun 2013, 10:11
Wohnort: Am Rand der Scheibe, 6 m unter NN

Re: Der AVR-/ARDUINO-Faden

Beitrag von Heaterman »

Ich denke mal, das Hauptproblem, das viele mit dem Treiber haben, ist das, dass der nicht richtig entpackt wird und die Leute in dem chinesischen Konfigurator des Treibers landen, statt das Setup zu finden, mit dem das Ding in einer Minute erledigt ist.
Benutzeravatar
Hightech
Beiträge: 11460
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Für den avr-dude gibt die Anleitung die Regeln so anzupassen, das die USB devices direkt beim einstecken der Gruppe dialout oder hier im Beispiel useres zugeordnet werden.
Irgenwo hier kann man auch festlegen, das ein bestimmtes USB Gerät immer auf z.B. ttyS05 gelegt wird

http://www.mikrocontroller.net/articles/AVRDUDE



Aus Mikrocontroller.net:

Code: Alles auswählen

Dies liegt daran, dass die device-nodes, die beim Einstecken des USB-Programmers von udev angelegt werden, root zugeordnet sind. Man kann dies ändern, indem man udev-Regeln für die verwendeten Programmer anlegt. Unter Debian muß man dazu nur eine neue Datei, z. B. 015_usbprog.rules unter /etc/udev/rules.d anlegen, z. B. mit folgenden Inhalt:


# Atmel AVR ISP mkII
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2104", GROUP="users", MODE="0660"

# usbprog bootloader
ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c62", GROUP="users", MODE="0660"
 
# USBasp programmer
ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="users", MODE="0660"
 
# USBtiny programmer
ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", GROUP="users", MODE="0660"


Danach muss in der Regel der udev-Dienst neu gestartet werden, was -- je nach System -- mit einem der beiden folgenden Befehle funktionieren sollte (natürlich nur als root):

sudo /sbin/udevadm control --reload-rules

bei aktueller udev-version, oder

sudo /sbin/udevcontrol --reload_rules
Benutzeravatar
zauberkopf
Beiträge: 9524
Registriert: So 11. Aug 2013, 15:33
Wohnort: gefährliches Halbwissen

Re: Der AVR-/ARDUINO-Faden

Beitrag von zauberkopf »

Hi !

Ich hatte mal ne Website gefunden, da konnte man ganz einfach für PWM sich die Register und sogar Code ausgeben lassen.
Also AVR Wählen, frequenz, verhältnis, pin.. und schwups war alles da.
Find ich blos nicht mehr wieder.

hat da jemand was für mich ?
lg Jan
Benutzeravatar
Hightech
Beiträge: 11460
Registriert: So 11. Aug 2013, 18:37

Problemchen

Beitrag von Hightech »

Moin, hab da mal ein Problemchen
Ich hab hier so ein Rfid U2270 Eval Board mit einem at90S8515 drauf.
Einen "passenden" Code habe ich auch gefunden.

Blöderweise konfiguriert er den INT0 als "trigger on falling and rising Edge"
Kacke, der 90S8515 kann nur trigger auf LOW, falling or rising.

Bild

Was mach ich denn jetzt ?

Kann ich sowas schreiben wie:
SIGNAL (SIG_INTERRUPT1)||(SIG_INTERRUPT0)
dann lasse ich den INT0 als rising und den INT als fallig laufen und packe das Signal auf beide Eingänge.

Oder kann ich den INTF0 nutzen ?

Also INT1 falling INFT=1 = interruptroutine INT0
INT0 rising = Interrupt routine INT0
Benutzeravatar
Fritzler
Beiträge: 12597
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Problemchen

Beitrag von Fritzler »

Hightech hat geschrieben:Dann lasse ich den INT0 als rising und den INT1 als fallig laufen und packe das Signal auf beide Eingänge.
Jo das würd ich auch so machen, aber dein Interruptaufruf geht so nicht.
Mach für jeden der beiden Interrupts ein Handler und beide rufen dieselbe Unterfunktion auf.

void feed_cookies(void){
//Interruptbehandlung
}

SIGNAL (SIG_INTERRUPT0){
feed_cookies();
}

SIGNAL (SIG_INTERRUPT1){
feed_cookies();
}
Benutzeravatar
Bauteiltöter
Beiträge: 254
Registriert: So 11. Aug 2013, 17:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bauteiltöter »

SIGNAL (SIG_INTERRUPT1)||(SIG_INTERRUPT0)

geht nicht, SIGNAL() ist ein Makro und expandiert zu einem normalen Funktionsaufruf (mit zusätzlichen Attributen), daher kann man das nicht so schreiben.

Fritzlers Ansatz ist schon der Richtige, abgesehen davon, das SIGNAL() schon seit Jahren "deprecated" ist und nicht mehr genutzt werden sollte.
avr-libc doku hat geschrieben:Deprecated: Do not use SIGNAL() in new code. Use ISR() instead.
Avr-libc.
ACHTUNG, wenn man ISR() statt SIGNAL() verwendet ändern sich die Vektor-Namen!
In deinem Fall INT0_vect und INT1_vect.

Und das ganze hat den Nachteil das der Compiler nicht mehr so gut optimieren muss, er muss alle caller-saved register sichern. Es sei denn es wird geinlined, da müsste man dann mal ins ELF schauen wenn man es genauer wissen möchte.


Eine Alternative, vermutlich die eleganteste, wäre auch das Makro ISR_ALIASOF, damit kann man zwei Interrupt-Vektoren mit einer ISR verknüpfen.

Das sähe dann so aus:

Code: Alles auswählen

ISR(INT0_vect) 
{
  //Dein Code hier
}

ISR(INT1_vect, ISR_ALIASOF(INT0_vect) );
Das ganze funktioniert aber erst ab GCC 4.2
Benutzeravatar
Fritzler
Beiträge: 12597
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Bauteiltöter hat geschrieben:Fritzlers Ansatz ist schon der Richtige, abgesehen davon, das SIGNAL() schon seit Jahren "deprecated" ist und nicht mehr genutzt werden sollte.
ich hab da nur SIGNAL geschrieben, weil das in HIghtechs Ausgangspost auch schon so stand :twisted:
Benutzeravatar
Hightech
Beiträge: 11460
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Jau, gute Idee.

Nun ist mir der AT90S8515 abgeraucht. Kotz !

Der Mega88 kann es ja von Hause aus.

Danke schön trotz dem !!
Benutzeravatar
Bauteiltöter
Beiträge: 254
Registriert: So 11. Aug 2013, 17:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bauteiltöter »

Moin Leute,

Ein großer Kritikpunkt an Arduino ist ja vor allem die Performance die so viel schlechter ist, deswegen habe ich mich in einem Anflug von Langeweile mal hingesetzt und einen einfachen Portzugriff zwischen Arduino und "klassischem" C gegenüber gestellt.
Alle Beispiele werden mit avr-gcc 4.5.1 und -Os als Optimierung kompiliert.

Einfache Aufgabe: Setze PD2 auf "high".

1. Versuch, klassischer Portzugriff bei AVRs, Bitgefrickel:

Code: Alles auswählen

#include <avr/io.h>
void f1(void)
{
	PORTD |= (1<<PD2);
}
avr-gcc -S -Os -mmcu=atmega328p test.c
macht daraus:

Code: Alles auswählen

	.file	"test.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__CCP__ = 0x34
__tmp_reg__ = 0
__zero_reg__ = 1
	.text
.global	f1
	.type	f1, @function
	f1:
	/* prologue: function */
	/* frame size = 0 */
	/* stack size = 0 */
	.L__stack_usage = 0
		sbi 43-32,2
	/* epilogue start */
		ret
	.size	f1, .-f1
Wenn man die Hinweise und zusätze für den Linker weglässt bleibt also das hier über:

Code: Alles auswählen

	f1:
		sbi 43-32,2
		ret
Ein einfaches sbi, optimaler geht es nicht mehr. In realem Code würde das vermutlich auch noch geinlined.

Jetzt zu der Arduino-Variante:

Code: Alles auswählen

void f2(void)
{
	digitalWrite(2,1);
}
Das geht natürlich nicht durch den Compiler, da fehlen ja die Funktionen. Also, auf ins Internet und in die innereien von Arduino. Kann ja nicht so viel Code sein den man dafür braucht, oder?
Eine halbe Stunde später und 300MB Sourcecode reicher hatte ich dann alles auf meinem Computer (ok, zugegeben, da ist auch der Sourcecode der Arduino-"IDE" dabei).

Code: Alles auswählen

#include <avr/io.h>
#include <avr/pgmspace.h>
#include <avr/interrupt.h>

#define cbi(port,bit) (port) &= ~(1 << (bit)) 

#define PB 2
#define PC 3
#define PD 4

#define NOT_A_PIN 0
#define NOT_A_PORT 0

#define HIGH 0x1
#define LOW  0x0

#define NOT_ON_TIMER 0
#define TIMER0A 1
#define TIMER0B 2
#define TIMER1A 3
#define TIMER1B 4
#define TIMER2  6
#define TIMER2A 7
#define TIMER2B 8

#define digitalPinToTimer(P) ( pgm_read_byte( digital_pin_to_timer_PGM + (P) ) )
#define digitalPinToBitMask(P) ( pgm_read_byte( digital_pin_to_bit_mask_PGM + (P) ) )
#define digitalPinToPort(P) ( pgm_read_byte( digital_pin_to_port_PGM + (P) ) )
#define portOutputRegister(P) ( (volatile uint8_t *)( pgm_read_word( port_to_output_PGM + (P))) )
const uint8_t PROGMEM digital_pin_to_port_PGM[] = {
        PD, /* 0 */
        PD,
        PD,
        PD,
        PD,
        PD,
        PD,
        PD,
        PB, /* 8 */
        PB,
        PB,
        PB,
        PB,
        PB,
        PC, /* 14 */
        PC,
        PC,
        PC,
        PC,
        PC,
};

const uint8_t PROGMEM digital_pin_to_timer_PGM[] = {
        NOT_ON_TIMER, /* 0 - port D */
        NOT_ON_TIMER,
        NOT_ON_TIMER,
        TIMER2B,
        NOT_ON_TIMER,
        TIMER0B,
        TIMER0A,
        NOT_ON_TIMER,
        NOT_ON_TIMER, /* 8 - port B */
        TIMER1A,
        TIMER1B,
        TIMER2A,
        NOT_ON_TIMER,
        NOT_ON_TIMER,
        NOT_ON_TIMER,
        NOT_ON_TIMER, /* 14 - port C */
        NOT_ON_TIMER,
        NOT_ON_TIMER,
        NOT_ON_TIMER,
        NOT_ON_TIMER,
};
const uint8_t PROGMEM digital_pin_to_bit_mask_PGM[] = {
        _BV(0), /* 0, port D */
        _BV(1),
        _BV(2),
        _BV(3),
        _BV(4),
        _BV(5),
        _BV(6),
        _BV(7),
        _BV(0), /* 8, port B */
        _BV(1),
        _BV(2),
        _BV(3),
        _BV(4),
        _BV(5),
        _BV(0), /* 14, port C */
        _BV(1),
        _BV(2),
        _BV(3),
        _BV(4),
        _BV(5),
};

const uint16_t PROGMEM port_to_output_PGM[] = {
        NOT_A_PORT,
        NOT_A_PORT,
        (uint16_t) &PORTB,
        (uint16_t) &PORTC,
        (uint16_t) &PORTD,
};

static void turnOffPWM(uint8_t timer)
{
        switch (timer)
        {
                case TIMER1A:   cbi(TCCR1A, COM1A1);    break;
                case TIMER1B:   cbi(TCCR1A, COM1B1);    break;
                case  TIMER0A:  cbi(TCCR0A, COM0A1);    break;
                case  TIMER0B:  cbi(TCCR0A, COM0B1);    break;
                case  TIMER2A:  cbi(TCCR2A, COM2A1);    break;
                case  TIMER2B:  cbi(TCCR2A, COM2B1);    break;
        }
}

void digitalWrite(uint8_t pin, uint8_t val)
{
        uint8_t timer = digitalPinToTimer(pin);
        uint8_t bit = digitalPinToBitMask(pin);
        uint8_t port = digitalPinToPort(pin);
        volatile uint8_t *out;

        if (port == NOT_A_PIN) return;

        // If the pin that support PWM output, we need to turn it off
        // before doing a digital write.
        if (timer != NOT_ON_TIMER) turnOffPWM(timer);

        out = portOutputRegister(port);

        uint8_t oldSREG = SREG;
        cli();

        if (val == LOW) {
                *out &= ~bit;
        } else {
                *out |= bit;
        }

        SREG = oldSREG;
}

void f2(void)
{
	digitalWrite(2,1);
}
Schnuckelige 140 Zeilen C, exklusive meiner aufrufenden Testfunktion "f2". Zu sehen sind einige Tabellen im Flash, Pointer werden dereferenziert, 101 Abfragen gegen Fehlbedienung... Zweifel kommen auf ob sich das ganze Effektiv kompilieren lässt.
avr-gcc -S -Os -mmcu=atmega328p test2.c bestätigt das ganze:

Code: Alles auswählen

	.file	"test2.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__CCP__ = 0x34
__tmp_reg__ = 0
__zero_reg__ = 1
	.text
.global	digitalWrite
	.type	digitalWrite, @function
digitalWrite:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
	ldi r25,lo8(0)
	movw r30,r24
	subi r30,lo8(-(digital_pin_to_timer_PGM))
	sbci r31,hi8(-(digital_pin_to_timer_PGM))
/* #APP */
 ;  121 "test2.c" 1
	lpm r18, Z
	
 ;  0 "" 2
/* #NOAPP */
	movw r30,r24
	subi r30,lo8(-(digital_pin_to_bit_mask_PGM))
	sbci r31,hi8(-(digital_pin_to_bit_mask_PGM))
/* #APP */
 ;  122 "test2.c" 1
	lpm r20, Z
	
 ;  0 "" 2
/* #NOAPP */
	subi r24,lo8(-(digital_pin_to_port_PGM))
	sbci r25,hi8(-(digital_pin_to_port_PGM))
	movw r30,r24
/* #APP */
 ;  123 "test2.c" 1
	lpm r24, Z
	
 ;  0 "" 2
/* #NOAPP */
	tst r24
	brne .+2
	rjmp .L1
	tst r18
	breq .L3
	cpi r18,lo8(3)
	breq .L6
	cpi r18,lo8(4)
	brsh .L10
	cpi r18,lo8(1)
	breq .L4
	cpi r18,lo8(2)
	brne .L3
	rjmp .L17
.L10:
	cpi r18,lo8(7)
	breq .L8
	cpi r18,lo8(8)
	breq .L9
	cpi r18,lo8(4)
	brne .L3
	rjmp .L18
.L6:
	lds r25,128
	andi r25,lo8(127)
	rjmp .L13
.L18:
	lds r25,128
	andi r25,lo8(-33)
.L13:
	sts 128,r25
	rjmp .L3
.L4:
	in r25,68-32
	andi r25,lo8(127)
	rjmp .L15
.L17:
	in r25,68-32
	andi r25,lo8(-33)
.L15:
	out 68-32,r25
	rjmp .L3
.L8:
	lds r25,176
	andi r25,lo8(127)
	rjmp .L14
.L9:
	lds r25,176
	andi r25,lo8(-33)
.L14:
	sts 176,r25
.L3:
	mov r30,r24
	ldi r31,lo8(0)
	lsl r30
	rol r31
	subi r30,lo8(-(port_to_output_PGM))
	sbci r31,hi8(-(port_to_output_PGM))
/* #APP */
 ;  132 "test2.c" 1
	lpm r18, Z+
	lpm r19, Z
	
 ;  0 "" 2
/* #NOAPP */
	movw r26,r18
	in r25,__SREG__
/* #APP */
 ;  135 "test2.c" 1
	cli
 ;  0 "" 2
/* #NOAPP */
	tst r22
	brne .L11
	ld r24,X
	com r20
	and r24,r20
	rjmp .L16
.L11:
	ld r24,X
	or r24,r20
.L16:
	st X,r24
	out __SREG__,r25
.L1:
	ret
	.size	digitalWrite, .-digitalWrite
.global	f2
	.type	f2, @function
f2:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
	ldi r24,lo8(2)
	ldi r22,lo8(1)
	call digitalWrite
/* epilogue start */
	ret
	.size	f2, .-f2
.global	main
	.type	main, @function
main:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
/* epilogue start */
	ret
	.size	main, .-main
.global	digital_pin_to_port_PGM
	.section	.progmem.data,"a",@progbits
	.type	digital_pin_to_port_PGM, @object
	.size	digital_pin_to_port_PGM, 20
digital_pin_to_port_PGM:
	.byte	4
	.byte	4
	.byte	4
	.byte	4
	.byte	4
	.byte	4
	.byte	4
	.byte	4
	.byte	2
	.byte	2
	.byte	2
	.byte	2
	.byte	2
	.byte	2
	.byte	3
	.byte	3
	.byte	3
	.byte	3
	.byte	3
	.byte	3
.global	digital_pin_to_timer_PGM
	.type	digital_pin_to_timer_PGM, @object
	.size	digital_pin_to_timer_PGM, 20
digital_pin_to_timer_PGM:
	.byte	0
	.byte	0
	.byte	0
	.byte	8
	.byte	0
	.byte	2
	.byte	1
	.byte	0
	.byte	0
	.byte	3
	.byte	4
	.byte	7
	.byte	0
	.byte	0
	.byte	0
	.byte	0
	.byte	0
	.byte	0
	.byte	0
	.byte	0
.global	digital_pin_to_bit_mask_PGM
	.type	digital_pin_to_bit_mask_PGM, @object
	.size	digital_pin_to_bit_mask_PGM, 20
digital_pin_to_bit_mask_PGM:
	.byte	1
	.byte	2
	.byte	4
	.byte	8
	.byte	16
	.byte	32
	.byte	64
	.byte	-128
	.byte	1
	.byte	2
	.byte	4
	.byte	8
	.byte	16
	.byte	32
	.byte	1
	.byte	2
	.byte	4
	.byte	8
	.byte	16
	.byte	32
.global	port_to_output_PGM
	.type	port_to_output_PGM, @object
	.size	port_to_output_PGM, 10
port_to_output_PGM:
	.word	0
	.word	0
	.word	37
	.word	40
	.word	43
Ein gewaltiger Code-Klotz. Um einen Pin zu setzen!
Flash-Größe ist dabei nicht mal das größte Problem, eher das die Ausführung ewigkeiten dauert.
Da das Teil echt unübersichtlich ist habe ich den C-Quelltext um eine main() erweitert und das ganze durchcompiliert, anschließend fördert ein Aufruf von avr-nm --size-sort --print-size folgendes zu Tage:

Code: Alles auswählen

Position | Größe | Art | Name
00000174 00000006 T main
0000016a 0000000a T f2
000000a4 0000000a T port_to_output_PGM
00000090 00000014 T digital_pin_to_bit_mask_PGM
00000068 00000014 T digital_pin_to_port_PGM
0000007c 00000014 T digital_pin_to_timer_PGM
000000c6 000000a4 T digitalWrite
6 Bytes für die Main, 10 Bytes für meine f2-Funktion.
Dann 10 und 3x 20 Bytes für die Übersetzungsmakros (bzw deren Tabellen im Flash) und 164 Bytes für die eigentliche digitalWrite()-Funktion. "Nur" diese 164 Bytes sind Code (und natürlich main/f2).

Fazit:
Der Laufzeitunterschied ist gewaltig. Beim AVR kann man halbwegs davon ausgehen das die Laufzeit linear mit der Codegröße wächst, mit mehr 160 Bytes für digitalWrite() im Gegensatz zu 4 Bytes für Bitshifts ist man also bei einem Geschwindigkeitsfaktor von ~40.

Und was ist der Vorteil? Ich kann keinen sehen.
Wenn man mit dem C-Syntax für Bitgefrickel nicht klar kommt, dann kann man das ganze auch hinter Makros verstecken. Oder, an der Stelle der Arduino-Ersteller, hätte man das ganze in ordentliche C++-Templates stopfen können. Das ist zwar für die Arduino-Entwickler komplizierter, dafür lässt es sich so schreiben, dass der Compiler es in zu einem einfachen "sbi" wegoptimieren kann. (Im Statischen Fall, wird der angesprochene Port/Pin variabel geht das natürlich nciht mehr so einfach. Das ist auch der einzige Vorteil des Arduino-Code, er wächst nicht mehr wenn man die Übergabeparameter an digitalWrite() Variable gestaltet, im Gegensatz zum C-Code, der dann etwas hässlicher würde. Allerdings ahbe ich diesen Fall noch in keinem Programm gehabt, das lässt sich eigentlich immer eleganter lösen).
Das Beispiel mit den C++-Templates war vor einiger Zeit mal im mikrocontroller.net.
Der Arduino-Code, so wie er jetzt ist, hat eigentlich nur den "Vorteil", das fehlerhafte Optionen zur Laufzeit abgefangen werden (wie z.B. if (port == NOT_A_PIN) return;) und der Code einfach "nicht funktioniert".
Beim C-Bitgeshifte funktioniert der Code auch nicht oder aber der Compiler warnt einen mit Meldungen wie "test.c:4:2: warning: left shift count >= width of type" (Im Falle von dicken Fingern z.B.).

Ich habe ehrlich gesagt wenig Zweifel daran, dass es bei anderen, grundlegenden Funktionien wie Timern/PWM, UART und I2C ähnlich aussieht. Libs auf höheren Ebenen wie LCD-Displays oder Sensoren dürften deutlich besser aussehen, abgesehen davon das sie auf die verkorksten Grundbibliotheken aufsetzen.

So, die akute Langeweile ist vorbei. Was ihr jetzt damit anfangt? Euer Bier.

lg
Bauteiltöter.
margau
Beiträge: 78
Registriert: Sa 7. Nov 2015, 23:15
Wohnort: Rhein-Main

Re: Der AVR-/ARDUINO-Faden

Beitrag von margau »

Hallo!
Ein bisschen muss ich den Arduino ja jetzt verteidigen.

Was ich zuerst zu sagen habe: So wie ich das sehe initialisiert der Arduino, bevor er in die Hauptschleife geht, auch noch diverse Timer die er für Dinge wie Delay oder millis() braucht. Das machst man beim reinen C natürlich nicht.

Desweiteren ist der Arduino darauf ausgelegt, mit Programmiertechnisch nicht ganz so begabten Leuten zu funktionieren. Jetzt erklär du denen mal, welchen Port sie wann setzten müssen, wo im 150-seitigen Datenblatt das steht.

Ich persönlich bin dankbar, dass es die Arduino-IDE gibt, mit sowas wird man nämlich deutlich einfacher an das richtige rangeführt. Und um ein paar LEDs Faden zu lassen reicht das auch.

Viele Grüße!
margau
Benutzeravatar
Fritzler
Beiträge: 12597
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Nö, das Setup hat er nicht mit kompiliert.
Bauteiltöter hat nicht per vergurkter A IDE compiliert, sondern die digitalWrite Funktion aus deren Libs compiliert.

Wie er auch sagte, gibt es bessere Wege dieses digitalWrite zu implementieren, sodass der compiler es dann doch wieder schafft ein sbi draus zu zaubern.

Wenn schon verteidigen, dann vorher den Text lesen und verstehen ;)
margau
Beiträge: 78
Registriert: Sa 7. Nov 2015, 23:15
Wohnort: Rhein-Main

Re: Der AVR-/ARDUINO-Faden

Beitrag von margau »

Ok, das mit dem Setup hab ich heute morgen nicht gesehen. Trotzdem sollte man meiner Meinung nach nicht so stark auf Arduino rumhaken, es ist wenn auch nicht optimal, für viele die beste/einzige Lösung.
Seit doch einfach froh das ihr es nicht braucht ;)

Und ja, man kann einiges besser lösen. Ich bin mir sicher die Arduino-Community freut sich über entsprechende Beiträge :D

Viele Grüße!
margau
Benutzeravatar
Heaterman
Beiträge: 3990
Registriert: Fr 28. Jun 2013, 10:11
Wohnort: Am Rand der Scheibe, 6 m unter NN

Re: Der AVR-/ARDUINO-Faden

Beitrag von Heaterman »

Lass Dich nicht von Fritzler ärgern, der hasst Arduinos eben und kanns nicht lassen... :)

Die Dinger erfüllen ihren Zweck und es wird keiner gezwungen, sie zu nehmen, aus, das brauchts keinen Richtungsstreit.
Benutzeravatar
Fritzler
Beiträge: 12597
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

?
Bauteiltöter wars!
Antworten