Der AVR-/ARDUINO-Faden
Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese
- Fritzler
- Beiträge: 12597
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Meine Güte, nehmt euch nen Zimmer...
Bzw nen VReg mit Enable Eingang und nich son Pfusch da...
Bzw nen VReg mit Enable Eingang und nich son Pfusch da...
-
- Beiträge: 3261
- Registriert: Mo 12. Aug 2013, 19:47
Re: Der AVR-/ARDUINO-Faden
Ich lösch's ja schon...
-
- Beiträge: 1506
- Registriert: Di 13. Aug 2013, 19:10
- Wohnort: Niedersachsen Süd-Ost
Re: Der AVR-/ARDUINO-Faden
Auf welchen Schaltungsvorschlag beziehst Du diese Aussage?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?
-
- Beiträge: 1506
- Registriert: Di 13. Aug 2013, 19:10
- Wohnort: Niedersachsen Süd-Ost
Re: Der AVR-/ARDUINO-Faden
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:Meine Güte, nehmt euch nen Zimmer...
Der Herr (Name vergessen) hat in seinem Post vom 31. Jan 2016 auf die Schaltung vom Transistortester hingewiesen. Aus der Schaltung extrahiere ich:Fritzler hat geschrieben:Bzw nen VReg mit Enable Eingang und nich son Pfusch da...
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?
- Fritzler
- Beiträge: 12597
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
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
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
-
- Beiträge: 3261
- Registriert: Mo 12. Aug 2013, 19:47
Re: Der AVR-/ARDUINO-Faden
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.Profipruckel hat geschrieben:Auf welchen Schaltungsvorschlag beziehst Du diese Aussage?
@ 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...
- Münsterländer
- Beiträge: 329
- Registriert: Fr 11. Okt 2013, 14:55
- Wohnort: Borken (bei Holland)
Re: Der AVR-/ARDUINO-Faden
@ 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...
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...
Re: Der AVR-/ARDUINO-Faden
Ansonsten kann man das auch mit einem MCP1702 lösen. Benötigt max. 2uA Ruhestrom + 1uA für den Controller mit Watchdog.Profipruckel hat geschrieben: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:Meine Güte, nehmt euch nen Zimmer...
Der Herr (Name vergessen) hat in seinem Post vom 31. Jan 2016 auf die Schaltung vom Transistortester hingewiesen. Aus der Schaltung extrahiere ich:Fritzler hat geschrieben:Bzw nen VReg mit Enable Eingang und nich son Pfusch da...
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?
Das ist weniger als die Selbstentladung der Batterie.
Re: Der AVR-/ARDUINO-Faden
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
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
-
- Beiträge: 71
- Registriert: So 11. Aug 2013, 15:47
Re: Der AVR-/ARDUINO-Faden
Sowas wie Produktaktivierung gibt es iirc beim Arduino und dessen Clones nicht.Daniel hat geschrieben: Den wollte ich aktivieren, es gelingt nicht.
Was genau willst du erreichen?Daniel hat geschrieben: Bekomme den Port nicht geändert usw.
Wie geht man vor wenn er neu aktiviert werden soll???
Was hast du probiert?
Kompilliert der Sketch oder steigt er dabei schon aus?
Zuckermais
Re: Der AVR-/ARDUINO-Faden
Hallo,Zuckermais hat geschrieben:Sowas wie Produktaktivierung gibt es iirc beim Arduino und dessen Clones nicht.Daniel hat geschrieben: Den wollte ich aktivieren, es gelingt nicht.Was genau willst du erreichen?Daniel hat geschrieben: Bekomme den Port nicht geändert usw.
Wie geht man vor wenn er neu aktiviert werden soll???
Was hast du probiert?
Kompilliert der Sketch oder steigt er dabei schon aus?
Zuckermais
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.
-
- Beiträge: 1506
- Registriert: Di 13. Aug 2013, 19:10
- Wohnort: Niedersachsen Süd-Ost
Re: Der AVR-/ARDUINO-Faden
Gut erkannt, ich habe weder BC558 noch schaltbare Spannungsregler daName 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.
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!
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.Fritzler hat geschrieben:Regler mit Enable habe ich wiederrum ne ganze Schublade voll im Aldi Sortimentskasten
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.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.
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.
Re: Der AVR-/ARDUINO-Faden
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.
- Fritzler
- Beiträge: 12597
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
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
Is da ne Zeitschrift mal wieder am Internet ausdrucken?
https://www.mikrocontroller.net/article ... programmer
avrdude hat nen Plugin für Linux SPI, was der RasPI ja hat
Is da ne Zeitschrift mal wieder am Internet ausdrucken?
Re: Der AVR-/ARDUINO-Faden
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.Fritzler hat geschrieben:Is da ne Zeitschrift mal wieder am Internet ausdrucken?
Re: Der AVR-/ARDUINO-Faden
Mir geht es auch darum, ob ich die Teile wieder retournieren soll.Daniel hat geschrieben:Hallo,Zuckermais hat geschrieben:Sowas wie Produktaktivierung gibt es iirc beim Arduino und dessen Clones nicht.Daniel hat geschrieben: Den wollte ich aktivieren, es gelingt nicht.Was genau willst du erreichen?Daniel hat geschrieben: Bekomme den Port nicht geändert usw.
Wie geht man vor wenn er neu aktiviert werden soll???
Was hast du probiert?
Kompilliert der Sketch oder steigt er dabei schon aus?
Zuckermais
kompilieren geht, aber den Fehler kann ich nicht deuten.
Originalsketch der im funzt I. Board von 2015 permanent.
Die Test LED und an Pin 13 blinken externe LED wie es nach dem Anlegen der Betriebsspannung sein soll.
Was mache ich verkehrt???
Re: Der AVR-/ARDUINO-Faden
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.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???
Re: Der AVR-/ARDUINO-Faden
Sorry, die Test LED auf dem Board blinkt.xoexlepox hat geschrieben: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.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???
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
Re: Der AVR-/ARDUINO-Faden
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?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.
-
- Beiträge: 3261
- Registriert: Mo 12. Aug 2013, 19:47
Re: Der AVR-/ARDUINO-Faden
Hatte er nicht das komplette Log gepostet? Aber ich seh's nicht mehr... habe ich das nur geträumt? Stand irgendwas drin von wegen ID nicht erkannt und veraltete Files und Device not found (COM irgendwas)...
Re: Der AVR-/ARDUINO-Faden
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
Ist das richtige Board ausgewählt?
Der richtige COM-Port?
Sagt der Geräte manager was zum Com-Port?
Viele Grüße!
margau
Re: Der AVR-/ARDUINO-Faden
Daniel hat geschrieben:Mir geht es auch darum, ob ich die Teile wieder retournieren soll.Daniel hat geschrieben:Hallo,Zuckermais hat geschrieben:Sowas wie Produktaktivierung gibt es iirc beim Arduino und dessen Clones nicht.Daniel hat geschrieben: Den wollte ich aktivieren, es gelingt nicht.Was genau willst du erreichen?Daniel hat geschrieben: Bekomme den Port nicht geändert usw.
Wie geht man vor wenn er neu aktiviert werden soll???
Was hast du probiert?
Kompilliert der Sketch oder steigt er dabei schon aus?
Zuckermais
kompilieren geht, aber den Fehler kann ich nicht deuten.
Originalsketch der im funzt I. Board von 2015 permanent.
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
-
- Beiträge: 3261
- Registriert: Mo 12. Aug 2013, 19:47
Re: Der AVR-/ARDUINO-Faden
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 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.
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
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.
- Münsterländer
- Beiträge: 329
- Registriert: Fr 11. Okt 2013, 14:55
- Wohnort: Borken (bei Holland)
Re: Der AVR-/ARDUINO-Faden
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.
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.
Re: Der AVR-/ARDUINO-Faden
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)
Re: Der AVR-/ARDUINO-Faden
Hallo und danke,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)
nach ich den China Treiber installierte, laufen beide Clone.
Gruß Daniel
Re: Der AVR-/ARDUINO-Faden
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
/**
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
- Bauteiltöter
- Beiträge: 254
- Registriert: So 11. Aug 2013, 17:37
Re: Der AVR-/ARDUINO-Faden
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.
Re: Der AVR-/ARDUINO-Faden
Hier war offensichtlich doch windoof gefragt.. aber trotzdem der vollständigkeit halber: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).
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.
Re: Der AVR-/ARDUINO-Faden
@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.
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.
Re: Der AVR-/ARDUINO-Faden
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.gafu hat geschrieben:Unter linux das gerät anstecken (USB) und dann einfach mal mit "dmesg" die letzten kernelmeldungen ansehen.
-
- Beiträge: 3261
- Registriert: Mo 12. Aug 2013, 19:47
Re: Der AVR-/ARDUINO-Faden
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.
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.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).
Re: Der AVR-/ARDUINO-Faden
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.
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.
Re: Der AVR-/ARDUINO-Faden
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
Viele Grüße!
margau
- 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
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.
-
- Beiträge: 1506
- Registriert: Di 13. Aug 2013, 19:10
- Wohnort: Niedersachsen Süd-Ost
Re: Der AVR-/ARDUINO-Faden
Kann ich bestätigen!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.
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.
- 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
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.
Re: Der AVR-/ARDUINO-Faden
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:
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
- zauberkopf
- Beiträge: 9524
- Registriert: So 11. Aug 2013, 15:33
- Wohnort: gefährliches Halbwissen
Re: Der AVR-/ARDUINO-Faden
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
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
Problemchen
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.
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
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.
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
- Fritzler
- Beiträge: 12597
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Problemchen
Jo das würd ich auch so machen, aber dein Interruptaufruf geht so nicht.Hightech hat geschrieben:Dann lasse ich den INT0 als rising und den INT1 als fallig laufen und packe das Signal auf beide Eingänge.
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();
}
- Bauteiltöter
- Beiträge: 254
- Registriert: So 11. Aug 2013, 17:37
Re: Der AVR-/ARDUINO-Faden
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.
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:
Das ganze funktioniert aber erst ab GCC 4.2
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.avr-libc doku hat geschrieben:Deprecated: Do not use SIGNAL() in new code. Use ISR() instead.
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) );
- Fritzler
- Beiträge: 12597
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
ich hab da nur SIGNAL geschrieben, weil das in HIghtechs Ausgangspost auch schon so standBauteiltöter hat geschrieben:Fritzlers Ansatz ist schon der Richtige, abgesehen davon, das SIGNAL() schon seit Jahren "deprecated" ist und nicht mehr genutzt werden sollte.
Re: Der AVR-/ARDUINO-Faden
Jau, gute Idee.
Nun ist mir der AT90S8515 abgeraucht. Kotz !
Der Mega88 kann es ja von Hause aus.
Danke schön trotz dem !!
Nun ist mir der AT90S8515 abgeraucht. Kotz !
Der Mega88 kann es ja von Hause aus.
Danke schön trotz dem !!
- Bauteiltöter
- Beiträge: 254
- Registriert: So 11. Aug 2013, 17:37
Re: Der AVR-/ARDUINO-Faden
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:
avr-gcc -S -Os -mmcu=atmega328p test.c
macht daraus:
Wenn man die Hinweise und zusätze für den Linker weglässt bleibt also das hier über:
Ein einfaches sbi, optimaler geht es nicht mehr. In realem Code würde das vermutlich auch noch geinlined.
Jetzt zu der Arduino-Variante:
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).
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:
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:
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.
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);
}
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
Code: Alles auswählen
f1:
sbi 43-32,2
ret
Jetzt zu der Arduino-Variante:
Code: Alles auswählen
void f2(void)
{
digitalWrite(2,1);
}
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);
}
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
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
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.
Re: Der AVR-/ARDUINO-Faden
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
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
- Fritzler
- Beiträge: 12597
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
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
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
Re: Der AVR-/ARDUINO-Faden
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
Viele Grüße!
margau
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
Viele Grüße!
margau
- 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
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.
Die Dinger erfüllen ihren Zweck und es wird keiner gezwungen, sie zu nehmen, aus, das brauchts keinen Richtungsstreit.
- Fritzler
- Beiträge: 12597
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
?
Bauteiltöter wars!
Bauteiltöter wars!