Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

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

Benutzeravatar
Torpert
Beiträge: 1416
Registriert: Mo 12. Aug 2013, 22:40
Wohnort: Saarland
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Torpert »

Ich konnte den Fehler immerhin wieder reproduzieren (Dank der Versionierung von syncthing konnte ich die alten Programmversionen wieder hervorholen) :P

Alle meine Versuche, der Ursache auf den Grund zu gehen, sind allerdings gescheitert. Jetzt rächt sich, dass ich nie eine ordentliche Einführung in das Thema durchgearbeitet habe, sondern immer nur soweit gefrickelt habe, bis mein Problem gelöst war. Naja, bei den bisherigen Progrämmchen, die immer auf eine Bildschirmseite gepasst haben, ging das ja noch.

Beim Versuch, MCUSR auszulesen (habe ich nicht hinbekommen :( ) habe ich gelesen, dass der Bootloader Sachen macht, die ich gar nicht kontrollieren kann. Ich habe dann einen ISP Programmer angeschlossen und mein Programm direkt aufgespielt. Beim rumprobieren, ob das Richtungsregister verloren geht (über einen Piezosummer an einem Kontrollpin) habe ich offenbar irgendwas gemacht, das nicht gut war. Das Board hat es jedenfalls nicht überlebt :oops:

Na gut, ich habe noch 2 andere ausrangierte Druckerboards rumliegen, kommt halt das nächste dran (zuerst ein Creality 1.1.4 Board mit atmega1284p). Und sieh an: das verhält sich wie erwartet, der Fehler tritt nicht auf :)

Ob das alte Board (vom Sunlu S8 Drucker, mit atmega2560) defekt war oder ob der Boardtyp den Fehler produziert, weiß ich jetzt auch nicht :?
Benutzeravatar
Torpert
Beiträge: 1416
Registriert: Mo 12. Aug 2013, 22:40
Wohnort: Saarland
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Torpert »

So, das Problem habe ich mit der anderen Hardware im Griff :P

Aber neues Rätsel:

Ich will mit dem Ausgang einens atmega den Eingang eines zweiten atmega schalten. Wie verdrahte ich das? Einfach GND <-> GND und DataPin <-> DataPin? Oder brauche ich noch eine Schutzbeschaltung?
Benutzeravatar
sukram
Beiträge: 3063
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

Wenn beide am gleichen Netzteil hängen, geht das. Um eventuelle Programmierfehler nicht in Schäden enden zu lassen, kannst du zwischen den Datenpins noch einen 150 Ohm Widerstand dazwischen hängen. Damit begrenzt der Fehlerstrom auf 33mA, falls beide Pins auf Ausgang stehen und 5V gegen GND treiben.

Wenn unterschiedliche Netzteile involviert sind, vorher mal überprüfen, ob die GND zueinander passen oder ob da Ausgleichströme fließen. Dann muss ggf ein Optokoppler oder ADUM dazwischen.
Benutzeravatar
Torpert
Beiträge: 1416
Registriert: Mo 12. Aug 2013, 22:40
Wohnort: Saarland
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Torpert »

sukram hat geschrieben: Do 13. Mai 2021, 09:54 Wenn beide am gleichen Netzteil hängen, geht das. Um eventuelle Programmierfehler nicht in Schäden enden zu lassen, kannst du zwischen den Datenpins noch einen 150 Ohm Widerstand dazwischen hängen. Damit begrenzt der Fehlerstrom auf 33mA, falls beide Pins auf Ausgang stehen und 5V gegen GND treiben.

Wenn unterschiedliche Netzteile involviert sind, vorher mal überprüfen, ob die GND zueinander passen oder ob da Ausgleichströme fließen. Dann muss ggf ein Optokoppler oder ADUM dazwischen.
Das hat funktioniert :P
Vielen Dank :)
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Logic Level Shifter für 12 V?

Beitrag von IPv6 »

Wieder mal eine nur artverwandte Frage, für die sich ein eigener Thread aber auch nicht lohnt.

Ich habe eine Woche Urlaub und wollte nach meinem letzten Nixieprojekt (Thermometer) nun die obligatorische Nixie-Uhr angehen.
Als Treiber sollen dieses mal HV5622 zum Einsatz kommen, damit lassen sich, im Gegensatz zu den klassischen 74141 BCD-to-DEC Treibern, mehrere Ausgänge gleichzeitig ansteuern was Spielereien mit Überblendungen erlaubt.

Jetzt will der HV5622 aber 12 V Logikspannung sehen, auch wenn viele im Netz das stumpf ignorieren und das Ding mit 5 V füttern.
Ich möchte den Treiber über die SPI Schnittstelle bedienen. Geplant ist, die maximalen 8 MHz auch auszunutzen, was zum flackerfreien dimmen der Zahlen nötig sein dürfte.

Also müssen irgendwie aus den 3,3 V vom ESP8266 12 V werden.
Die typischen Logic Level Shifter versagen bei solchen Frequenzen.
Spezielle Logiv Level Shift ICs nehmen? Die meisten scheinen allerdings für den Bereich von 1,8 V bis 5 V gemacht zu sein.
Einen Gatetreiber für MOSFETs verwenden? Hatte ich noch nie was mit zu tun, gibt es da typische Vertreter, die man gerne nimmt?

Läuft wohl eh auf eine Digikey Bestellung raus, können daher auch gerne Bauteile sein, die man nicht an jeder Ecke bekommt. Sollten halt nicht gerade ein Vermögen kosten.
Benutzeravatar
Raja_Kentut
Beiträge: 1528
Registriert: Mi 14. Aug 2013, 13:11
Wohnort: Veitsbronn-Bernbach

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raja_Kentut »

mein erster millis() Versuch.
Das Fenster soll im Automatikmodus ( Programmteil fenster_oeffnen_auto () ) nur dann geöffnet werden ( Programmteil fenster_oeffnen(); wird angesprungen), wenn mindestens 10 Minuten vergangen sind nach der letzten Fensteröffnung.
Das soll verhindern, das das Fenster vorübergehend immer auf- und zu geht weil ein Wetterwechsel laaaaangsam kommt.
(V4) in den Kommentaren markiert die Änderungen zur Vorgängerversion

Bevor ich in den Keller latsche, das Elektronikgehäuse aufmache den Code reinlade und feststelle das es nicht funktioniert meine Frage an die Prorgammierkönner :
Funktioniert das so ? Das ist meine Idee dazu:

Code: Alles auswählen

// ******* ÖFFNEN AUTOMATIKBETRIEB *******
void fenster_oeffnen_auto ()                      // Starten der Funktion Fenster öffnen NUR wenn Aussen wärmer als Innen (Zylinder Eingefahren = fenster auf)
{
 timer_delay = millis(); 
 timer_delay_alt = timer_delay;                         //(V4) aktuellen Timerwert abspeichern in timer_delay_alt
  
  if(gradC_Ai < gradC_Ii)                        // wenn Aussentemperatur kleiner Innentemperatur (Integerwerte) dann Fenster schließen
    {
     fenster_schliessen();                       // Routine fenster_schliessen anspringen
    }
      else if (timer_delay - timer_delay_alt < 300000) // (V4)sonst fenster öffnen  WENN seit letztem Aufruf mind 10 Minuten vergangen sind
      {
       fenster_oeffnen();                       // Routine fenster_oeffnen anspringen
      }
}
Anfengergrühse,
RK
Benutzeravatar
Später Gast
Beiträge: 1680
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Später Gast »

das kann so nicht funktionieren, weil jedes Mal, wenn fenster_oeffnen_auto () aufgerufen wird, ist timer_delay==timer_delay_alt. Du musst dafür sorgen, dass timer_delay_alt nur dann geupdatet wird, wenn die 10 Minuten auch vorbei sind und nicht jedes Mal, wenn deine Funktion aufgerufen wird. Aber selbst dann wird die Bedingung immer wahr sein, weil du < anstatt > verwendet hast.

Ich mache das so, dass der Vergleich als If-Bedingung vor dem Aufruf der Funktion im Loop()kommt und in der Funktion dann der Timer resettet wird.
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Auch wenn ich kein Programmierprofi bin, das scheint noch einnpaar Problemchen zu haben.

timer_delay und timer_delay_alt haben immer den selben Wert. Den alten Wert solltest du erst setzen, wenn die Zeitbedingung einmal erfüllt war, damit sich dieser Zeitpunkt gemerkt wird. Im aktuellen Zustand kann deine Überprüfung nie wahr werden.

Wenn ich deine Logik richtig verstanden habe müsste das Vergleichszeichen anders rum sein, denn die aktuelle Zeit minus die alte Zeit muss größer als deine gewünschte Dauer sein damit genug Zeit vergangen ist.

Und zuletzt sind 300000 ms nicht 10 Minuten.
Benutzeravatar
Raja_Kentut
Beiträge: 1528
Registriert: Mi 14. Aug 2013, 13:11
Wohnort: Veitsbronn-Bernbach

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raja_Kentut »

klar, die 300000 sind nur 5 Minuten :lol:

ich hab jetzt die Umspeicherung NACH fenster öffnen() gelegt und den Vergleich auf GRÖßER umgestellt
Hauptprogramm springt nach fenster_oeffnen_auto () -> timer_delay = millis() [sagen wir aktuell 1000, beim vorigen Durchlauf 900]
(timer_delay - timer_delay_alt > 300000) ergibt 1000-900 = 100 ->NICHT erfüllt, also fenster_oeffnen() wird nicht ausgeführt,
jetzt wird timer_delay_alt = timer_delay =1000.

6 Minuten lang wird fenster_oeffnen_auto () nicht angesprungen -> timer_delay = millis() = 361000
(timer_delay - timer_delay_alt > 300000) ergibt 361000-1000 = 360000 -> erfüllt, fenster_oeffnen() wird angesprungen
jetzt wird timer_delay_alt = timer_delay =36000.

so müßte es doch gehen:

Code: Alles auswählen

// ******* ÖFFNEN AUTOMATIKBETRIEB *******
void fenster_oeffnen_auto ()                      // Starten der Funktion Fenster öffnen NUR wenn Aussen wärmer als Innen (Zylinder Eingefahren = fenster auf)
{
 timer_delay = millis();                                //(V4) timer_delay mit Wert aus millis Timer laden
  if(gradC_Ai < gradC_Ii)                        // wenn Aussentemperatur kleiner Innentemperatur (Integerwerte) dann Fenster schließen
    {
     fenster_schliessen();                       // Routine fenster_schliessen anspringen
    }
      else if (timer_delay - timer_delay_alt < 300000) // (V4)sonst fenster öffnen  WENN seit letztem Aufruf mind 5 Minuten vergangen sind
      {
       fenster_oeffnen();                       // Routine fenster_oeffnen anspringen
      }
 timer_delay_alt = timer_delay;                  //(V4) aktuellen Timerwert abspeichern in timer_delay_alt
}
Benutzeravatar
Später Gast
Beiträge: 1680
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Später Gast »

Dein Größer-Zeichen hat sich der Geschlechtsumwandlung widersetzt und lebt weiterhin im falschen Körper. ;)
Du musst die Umspeicherung in der if Bedingung machen, sonst schlägt das womöglich wieder fehl, weil die ganze Funktion zu oft aufgerufen wird und zwischen den Aufrufen keine 5 Minuten vergehen.


Wenn du mit timer_delay keine Rechenoperationen machst und die nur da für genau diesen Zweck verwendet wird, brauchst du die Variable wahrscheinlich nicht und kannst in deiner if-Bedingung direkt millis()-timer_delay_alt>Zeitintervall rechnen, sparst du dir eine unsigned long.
also so:

Code: Alles auswählen

else if (millis() - timer_delay_alt > 300000) // (V4)sonst fenster öffnen  WENN seit letztem Aufruf mind 5 Minuten vergangen sind
      {
       fenster_oeffnen();                       // Routine fenster_oeffnen anspringen
       timer_delay_alt = millis();                  //(V4) aktuellen Timerwert abspeichern in timer_delay_alt
      }
Benutzeravatar
Raja_Kentut
Beiträge: 1528
Registriert: Mi 14. Aug 2013, 13:11
Wohnort: Veitsbronn-Bernbach

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raja_Kentut »

ah, danke !
ich werde das mal so probieren.
Wegen der timer_delay : Ich hab ja noch Platz für Variablen, und irgendwie brauch ich immer alles sehr deutlich ums nach einiger Zeit zu verstehen...Programmieren ist für mich so, wie für einen Gerüstbauer das Rhababertörtchenverzieren. Aber das wird schon noch....
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Bin grad hier drüber gestolpert:
Industrie Arduino
https://www.controllino.shop/c/shop
Benutzeravatar
Torpert
Beiträge: 1416
Registriert: Mo 12. Aug 2013, 22:40
Wohnort: Saarland
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Torpert »

[edit] - Problem gelöst :P

Ich habe für mein realitätsgetreues RC-Projekt (viewtopic.php?f=14&t=18529) einen atmega als Servomanipulator geplant. Dieser Prototyp funktioniert schon mal grundsätzlich:
IMG_20211111_153422.jpg
Das ist ein atmega8, der mit 8 MHz internem Takt läuft. Am Eingang hängt hier ein Servotester (und an dem noch ein Servo zur Kontrolle). Am Ausgang des atmega8 hängt ein baugleicher Servo.

Ich habe im Wesentlichen diese Lib benutzt: http://davidegironi.blogspot.com/2017/0 ... Y0rCGDMKHs und gebe den eingelesenen Wert am Ausgang wieder aus. Welche Manipulationen ich am Wert vornehme, kommt später. Momentan gebe ich ihn unverändert aus, um das Prinzip zu testen.

Grundsätzlich klappt das, beide Servos fahren immer in die gleiche Stellung. Nur der Servo am atmega zappelt manchmal los. Nicht viel, aber spürbar.

Was mache ich am besten dagegen? Das Ausgangssignal in Software glätten? Den Ausgang mit einem Kondensator oder sowas beruhigen? Oder habe ich einen grundsätzlichen Fehler eingebaut?

[edit] Nachtrag: Ich habe testweise einen konstanten Wert ausgegeben. Das Ding zappelt immer noch :?
[edit] Nochmal Nachtrag: Ich hab's gefunden, das Gezappel kommt über die Spannungsversorgung rein. Ich habe das Gammel-Handyladegerät gegen ein richtiges Netzteil getauscht, schon zappelt es kaum noch. Im Modellauto ist das Problem wahrscheinlich nicht mehr existent.
Benutzeravatar
Bastelbruder
Beiträge: 11482
Registriert: Mi 14. Aug 2013, 18:28

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bastelbruder »

Der Digitalismus sollte sich von Fluktuationen der Betriebsspannung nicht beeinducken lassen. Garnicht. Niemals!
Benutzeravatar
Torpert
Beiträge: 1416
Registriert: Mo 12. Aug 2013, 22:40
Wohnort: Saarland
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Torpert »

Stimmt - wenn man alles richtig macht. Ich habe allerdings ein wenig dilletiert 🙈

Die Steckbrettschaltung hatte 2 Spannungsversorgungen gleichzeitig, einmal vom Netzteil und einmal aus dem Programmer. Wenn ich das Netzteil abgeklemmt hatte, ging nix mehr. Und wenn ich den Programmer abgeklemmt hatte, auch nicht. Also habe ich nicht weiter überlegt und beide dran gelassen.

Jetzt habe ich doch mal ins Datenblatt reingeguckt und einen PullUp an die Resetleitung geklemmt. Jetzt läuft das Teil auch mit dem Netzteil alleine. Und ganz ohne das kleinste Zucken :P
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

Die SDfat library (von Greiman )gibt's ja in version 2.
bei der ver1 war ein bintocsv.cpp dabei, was bei der neuen fehlt.
wenn man die headerdatei von der neuen übernimmt

Code: Alles auswählen

//#include "AnalogBinLogger.h"
#include "AvrAdcLogger.h"
und

Code: Alles auswählen

if (sizeof(meta) != 512 || sizeof(adc) != 512) {
    printf("block size error\n");
    return 0;
  }
512 durch 64 ersetzt, tut das auch mit den neuen (bin)daten.
Benutzeravatar
Weisskeinen
Beiträge: 3942
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

Mal für Doofe: was tut es und was hat die Änderung für Auswirkungen?
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

es tut binär geloggte Daten(AvrAdcLogger.ino), am PC, in csv konvertieren.
weil die Struktur der Bin Datei sich geändert hat, tut das nicht mehr.
Die Struktur steht in der der header Datei, deshalb muss man die neue nehmen.

Wer das braucht und nicht kompilieren kann möge mich per pn um die exe anfragen. ohne gewehr
xanakind
Beiträge: 12538
Registriert: So 11. Aug 2013, 21:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von xanakind »

Ich bin gerade dabei, aus mehreren defekten Arduino Nanos ein paar funktionierende zusammenzubraten.

Die stammen alle aus dem Firmenschrott.
Meistens ist die CPU defekt, manchmal aber auch der CH340.
Aus irgendwelchen Schrottgeräten habe ich ein paar passende CPU´s gefunden und eingelötet :mrgreen:
Von einem fabrikneuen Arduino habe ich über ISP den Code ausgelesen und auf meine reparierten gebrannt.
Soweit alles ok, die LED blinkt.
Über die Arduino Oberfläche kann ich sie über USB allerdings nicht ansprechen.
Das Hochladen schlägt immer fehl :(

Testweise habe ich das ganze auch mal mit einem fabrikneuen Arduino versucht, hier das gleiche.
Einen Hardwarefehler schließe ich somit also aus.
Was könnte denn noch falsch sein?
Die Fusebits stimmen alle.
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Fehlt der Bootloader vielleicht?
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Du kannst einen fabrikneuen Arduino nicht "ganz normal" bespielen?
Klassiker bei chinesischen Nanos wäre es, wenn du in den Einstellungen "old Bootloader" auswählen müsstest.
Oder mal eine USB2.0 Buchse probieren, ich hatte mal unerklärliche Probleme an einem 3.0er Anschluss.

Sonst die Boards einfach per ISP Schnittstelle programmieren?
Ein passendes Werkzeug scheinst du dafür ja zu haben, einfach beim Hochladen anklicken die Shifttaste gedrückt halten.
Damit lässt sich dann auch der Bootloader auf den µC flashen, spart das Gedöst von wegen alten µC auslesen.
Benutzeravatar
phettsack
Beiträge: 1184
Registriert: Mo 12. Aug 2013, 18:17

Re: Der AVR-/ARDUINO-Faden

Beitrag von phettsack »

Hightech hat geschrieben: So 14. Nov 2021, 19:17 Fehlt der Bootloader vielleicht?
Das könnte gut möglich sein, ich hatte hier auch schon einige die gar keinen Bootloader hatten. Prinzipiell kann man den einfach per Arduino-IDE draufbrutzeln, den entsprechenden Adapter vorausgesetzt.
Allerdings hatte ich auch schon den richtigen Adapter (TinyUSBASP), aber der PC wollte nicht. An einem Laptop gings dann. Warum auch immer.
Wenn man einmal die Bootloader drauf hat ist das Leben wieder schön :-)
xanakind
Beiträge: 12538
Registriert: So 11. Aug 2013, 21:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von xanakind »

Ja, einen frischen und neuen Arduino kann ich ganz normal bespielen.
Das funktioniert.
Das mit dem "Old Bootloader" ist bekannt, daran hängt es aber nicht
xanakind
Beiträge: 12538
Registriert: So 11. Aug 2013, 21:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von xanakind »

phettsack hat geschrieben: So 14. Nov 2021, 19:24 Allerdings hatte ich auch schon den richtigen Adapter (TinyUSBASP), aber der PC wollte nicht. An einem Laptop gings dann. Warum auch immer.
Wenn man einmal die Bootloader drauf hat ist das Leben wieder schön :-)
Das muss ich mal testen.
Aktuell funktioniert mein AVR ISP MKII unter Windows 10 wieder nicht.
Mal schauen, warum er denn diesmal nicht geht.
Die Firmware habe ich mit dem unter Windows XP gebrannt, das geht immer :D
bastelheini
Beiträge: 1663
Registriert: So 11. Aug 2013, 13:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von bastelheini »

Ha, hatte eben gerade das gleiche. MK2 wird im AVR Studio erkannt, im Arduino nicht. Per Bootloader ging auch nicht, der hat wohl gefehlt/war der falsche.

Hab folgende Datei draufgehauen C:\Program Files (x86)\Arduino\hardware\arduino\avr\bootloaders\optiboot\optiboot_atmega328.hex

Fuses hab ich so gelassen wie sie waren:

Code: Alles auswählen

BODLEVEL = 2V7
RSTDISBL = [ ]
DWEN = [ ]
SPIEN = [X]
WDTON = [ ]
EESAVE = [ ]
BOOTSZ = 1024W_3C00
BOOTRST = [X]
CKDIV8 = [ ]
CKOUT = [ ]
SUT_CKSEL = EXTXOSC_8MHZ_XX_16KCK_14CK_65MS

EXTENDED = 0xFD (valid)
HIGH = 0xDA (valid)
LOW = 0xFF (valid)
Jetzt kann ich auch via serieller Schnittstelle in Arduino flashen. MK2 hab ich dort nicht zum laufen gebracht, da meckert er rum:

Code: Alles auswählen

avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : usb
         Using Programmer              : stk500v2
avrdude: usbdev_open(): did not find any USB device "usb" (0x03eb:0x2104)

avrdude done.  Thank you.

Beim Hochladen des Sketches ist ein Fehler aufgetreten
xanakind
Beiträge: 12538
Registriert: So 11. Aug 2013, 21:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von xanakind »

Danke, ich werde das mal testen.
Was ist nicht verstehe:
Ich habe einen funktionierenden mit meinem MKII ausgelesen und die beiden Files (Flash / EEPROM) 1:1 auf die reparierten gebrant.
Da müsste doch der funktionierende Bootloader gleich mit drauf sein?
xanakind
Beiträge: 12538
Registriert: So 11. Aug 2013, 21:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von xanakind »

Tatsache!
Ich habe nun das Hex-File über ISP gebrannt.
Danach kann ich mein Testfile (Blink LED) über die adruino Oberfläche ganz normal hochladen.

Dankeschön! :D
bastelheini
Beiträge: 1663
Registriert: So 11. Aug 2013, 13:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von bastelheini »

Vielleicht kann ein Wissender nochmal die Fuse mit der Bootsektorgröße prüfen. Nicht dass da was falsch ist und einem später gegens Bein läuft.
Benutzeravatar
Torpert
Beiträge: 1416
Registriert: Mo 12. Aug 2013, 22:40
Wohnort: Saarland
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Torpert »

Ich habe gerade die Einfachheit von micropython und die Power des Raspi Pico zusammen entdeckt :o
Ist vielleicht ein alter Hut für viele von euch, aber wer wie ich noch mit atmega8 und Co. rumdoktert und mit c nie warm wurde: probiert den mal aus :P

Der Chip hat 2 Kerne, die von micropython unterstützt werden. Ich kann ganz faul 2 threads parallel laufen lassen. Einer sammelt die Eingänge ein und der andere wertet und gibt aus. Ist vielleicht nicht die effizienteste Vorgehensweise, aber die Hardware ist offenbar schnell genug um das zu kompensieren. Und ganz ohne Gehirnakrobatik :)
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

bastelheini hat geschrieben: So 14. Nov 2021, 21:27 Vielleicht kann ein Wissender nochmal die Fuse mit der Bootsektorgröße prüfen. Nicht dass da was falsch ist und einem später gegens Bein läuft.
kann xanakind ja nur selber. die default fuses stehen in der boards.txt und sind gleich für neu/alt.
Benutzeravatar
Torpert
Beiträge: 1416
Registriert: Mo 12. Aug 2013, 22:40
Wohnort: Saarland
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Torpert »

Ich habe mir einen Tiny 2040 von Pimoroni zum Probieren geholt:
IMG_20211119_122235.jpg
Funktioniert auf Anhieb mit der identischen Micropython-Firmware vom Raspi Pico :)

Er ist schön klein und hat einen USB-C Stecker. Dafür kostet er auch das Doppelte vom Raspi ;)

Ich habe noch einen Adafruit QT Py 2040 hier, aber noch nicht ausprobiert:
IMG_20211119_115211.jpg
Benutzeravatar
erwin
Beiträge: 709
Registriert: Do 15. Aug 2013, 08:57
Wohnort: 68642 Bürstadt
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von erwin »

Arduino Spezialist Gesucht

Hallo ich suche jemand der mir Merlin auf ein MKS Base V 1.4 Board auf spielt
Es ist für ein 3D Drucker
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

Also ich verstehe das mit Millis immer noch nicht.

Wir haben ein Programm, was mit Delays arbeitet und das soll auf millis umgeschrieben werden.

Das Ausgangsprogramm ist das:

#define ICPin 3 // Pin Einlesen IC
#define RelaisPin 5 // Pin Schalten Relais

void setup() {
// put your setup code here, to run once:
pinMode(ICPin,INPUT);
pinMode(RelaisPin,OUTPUT);
digitalWrite (RelaisPin, LOW);
}

void loop() {
// put your main code here, to run repeatedly:
digitalWrite (RelaisPin, HIGH);
if (digitalRead(ICPin)==HIGH)
{
delay (650); //Wartezeit bis Relais abgeschaltet wird
digitalWrite (RelaisPin, LOW);
delay (20000);
}
}

Also kein Hexenwerk.

Wir werten eine positive Flanke eines ICs aus, setzen ein Relais am Anfang auf AN, dann wenn das Signal
kommt, wird das Relais nach 650 ms abgeschaltet und nach 20 Sekunden wieder an.

So funktioniert das schon mal, aber da der Arduino später noch was parallel machen soll, sollen die Zeiten
durch millis ersetzt werden.

Ich verstehe nicht mal im Ansatz, wie dasmit millis geht, daher bringen Tipps wie "Lies da und da." nichts.
Benutzeravatar
Später Gast
Beiträge: 1680
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Später Gast »

millis() gibt die Millisekunden seit boot an und ist eine unsigned int. Wenn du die Zeit messen willst speicherst du zum Startpunkt den Wert von millis() in einer globalen unsigned int.

millis() läuft davon unberührt weiter. Wenn du jetzt die Differenz der beiden Werte bildest hast du die seit Startpunkt abgelaufene Zeit in Millisekunden.

Das packst du dann in einen vergleich.

Also zu Beginn
Startpunkt =millis();

Und dann if(millis()-Startpunkt>1000){ do something;}

Dann musst du noch dafür sorgen, dass die erste Zeile nicht dauernd aufgerufen wird, sonst sind Startpunkt und millis ja immer identisch.
MSG
Beiträge: 2182
Registriert: Fr 9. Nov 2018, 23:24
Wohnort: Nähe Dieburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von MSG »

Cubicany hat geschrieben: Mi 24. Nov 2021, 13:19Also ich verstehe das mit Millis immer noch nicht.
Das macht nichts. Deswegen wurde es ja hier im Thread schon durchgekaut ;-)

Ich hatte da ein Vorschlag gemacht viewtopic.php?p=354321#p354321 und prompt wurde ich auf Fehler in meiner Logik hingewiesen (siehe den Beitrag drunter, danke nochmal an dieser Stelle :-) )
Benutzeravatar
Toni
Beiträge: 2523
Registriert: Di 13. Aug 2013, 18:24

Re: Der AVR-/ARDUINO-Faden

Beitrag von Toni »

erwin hat geschrieben: Mo 22. Nov 2021, 07:45 Arduino Spezialist Gesucht

Hallo ich suche jemand der mir Merlin auf ein MKS Base V 1.4 Board auf spielt
Es ist für ein 3D Drucker
Ich hatte damals das RAMPS 1.4 mit Marlin bespielt, das sollte kompatibel sein. Aufspielen war das kleinste Problem: Arduino auf dem PC installieren, USB-Kabel dran, ATMega2560 auswählen, Marlin-Projekt öffnen, Upload, fertig.
Für mich war es wie die Pest Marlin an meinen Drucker anzupassen ohne dass es dabei wegen falschen Anpassungen unkompilierbar wird...

Hast du schon die richtige Marlin Version für deinen Drucker?
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Später Gast hat geschrieben: Mi 24. Nov 2021, 13:50 ...einer globalen unsigned int.
Sorry fürs Klugscheißen:
unsigned long bitte, damit es der selbe Datentyp ist wie die Funktion millis() zurückgibt und beide gleichermaßen überlaufen. Sonst gibt es Probleme nach ein paar Wochen Betrieb.
Jannyboy
Beiträge: 1406
Registriert: So 11. Aug 2013, 14:49
Wohnort: Kreis Augsburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Jannyboy »

Unsigned int geht auch, solange keine Zeitspanne länger als unsigned int ist.

Nur vorsichtig muss man sein... uint kann je nach Architektur unterschiedliche Größen haben. Zwischen 2 und 8 bzw. 16 Byte. Ganz sicher schreibt man uint32_t.

Grüße Jan
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Cubicany hat geschrieben: Mi 24. Nov 2021, 13:19 So funktioniert das schon mal, aber da der Arduino später noch was parallel machen soll, sollen die Zeiten
durch millis ersetzt werden.
Das ist blödfug.
Wenn man eine Zeit präzise haben will und nebenbei anderes Zeug machen will nimmt man einen Timer und einen Interrupt.
Benutzeravatar
Später Gast
Beiträge: 1680
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Später Gast »

IPv6 hat geschrieben: Mi 24. Nov 2021, 21:37
Sorry fürs Klugscheißen:
unsigned long.
Nee ich sorry, du danke!

Bin grad etwas neben der Spur und schreib vom Schmierfon, hab natürlich unsigned long gemeint. :oops:
Wenn man zum Platzsparen ne kleinere Variable nehmen will sollte man schon sicherstellen, dass die nicht überläuft, sonst Bug, das hätte ich dann dazugeschrieben.
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Unsigned long macht nach 50 Tagen einen Überlauf.
Wenn der Aparillo dann im richtig/falschen Moment die millis nimmt, bleibt das Relais sehr lange an, oder das Programm bleibt 50 Tage in der Warteschleife.
Benutzeravatar
Später Gast
Beiträge: 1680
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Später Gast »

Hightech hat geschrieben: Do 25. Nov 2021, 07:43 Unsigned long macht nach 50 Tagen einen Überlauf.
Wenn der Aparillo dann im richtig/falschen Moment die millis nimmt, bleibt das Relais sehr lange an, oder das Programm bleibt 50 Tage in der Warteschleife.
nope.
Durch das bilden der Differenz passiert eben das nicht. Dann läuft das Ergebnis auch über, Ergebnis ist das Gleiche wie ohne Überlauf.
Benutzeravatar
Harley
Beiträge: 1160
Registriert: So 11. Aug 2013, 21:16
Wohnort: Regensburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Harley »

Ich tu mir das nicht mehr an.
Für 4,50€ bekomme ich einen Raspberry Pi Pico.
Die C++ Jünger bekommen jetzt vermutlich Schnappatmung und grüne und gelbe Punkte im Gesicht.

Ich programmiere seit über 40 Jahren! Habe aber nie professionell in der Oberliga gespielt, weil ich beruflich da recht schnell raus war.
Ich finde es aber sensationell, was heute mit Micropython geht.
Gerade für Anfänger toll. Viele wollen ja gar keine Top-Programmierer werden, sondern blos ein paar kleine Sachen zum Laufen bringen.
In Thonny kann man jeden Befehl sofort ausprobieren, das übertragen des Programmes geht in Windeseile.

Der Pico spielt den Arduino mühelos in allen Disziplinen an die Wand!

Exakte Zeiten z.B.:
Codeschnipsel.jpg
(Auszug aus dem Buch "Messen Steuern und Regeln mit Micropython und RP2040" von H.J. Berndt, absolut empfehlenswert!)

Das stimmt auf die Millisekunde genau!

Man kann den Vergleich auch mit der Funktion time.ticks_diff() machen, dann werden Überläufe automatisch berücksichtigt.
Um Variablendefinitionen braucht man sich auch nicht zu kümmern.

Es gibt auch time.ticks_us und sogar time.ticks_ns !

Messwerte in Datei schreiben, Displays, Sensoren und und und, alles total pillepalle.
Mir kommt es nur noch drauf an, dass es schnell geht und problemlos funktioniert.

Ich bin von Micropython begeistert!
Benutzeravatar
Harley
Beiträge: 1160
Registriert: So 11. Aug 2013, 21:16
Wohnort: Regensburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Harley »

Kleines Beispiel:

Ich habe 2 Stromzähler mit S0 Ausgang. Einen an der Solaranlage und einen im Zugang zum Haus.
Also Solarertrag und Verbrauch.
Ich will eine 2/4/6 kW Heizpatrone in die Heizung einbauen und den Überschuß in die Heizung pfeffern.
Das muss natürlich sauber gesteuert werden.

Also das S0 Signal (1 Impuls / wh) auswerten. In der Periodendauer steckt die Leistung.
code s0.jpg
Das writer-Modul ist nur wegen der großen Schriftart drin. Ich kann die Fuzzelschrift sonst nicht lesen.
Die 0 und die 10000 in der print-Ausgabe sind dazu da, die Autoskalierung des Kennlinienschreibers in Thonny auszubremsen.
Die 30ms Pause ist nur drin, damit man die LED sehen kann (S0-Impuls-Kontrolle)
Der Pico macht in der Hauptschleife genau nichts (immer nur 100S pennen).
Die Gaudi ist Interruptgesteuert.

Mach das Alles mal auf die Schnelle mit nem Arduino ...

So sieht das dann aus:
P1070041.JPG
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

Weil ich meinen Uno für was anderes brauche,hab ich mir einen Nano als ISP programmer zurecht gemacht.
Bin dem Bauvorschlag gefolgt und hab eine rgb LED eingebaut zur Status Anzeige.
die leuchtet jetz rot grün und blau, unabhängig davon ob ein Vorgang klappt oder nicht, weil zb gar nix dran hängt.
was soll der quatsch? oder bin ich zu doof?
ich sag erst mal: Nutzlos, schade um die led und die widerstände :(
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

Wie genau funktioniert das am Arduino denn mit dem Timer und Interrupt?

Da steigt es bei mir komplett aus.

Habe schon Videos gesehen und was dazu gelesen, aber absolut keine Ahnung, wie das gehen soll.

Gibt es da irgendwo was, was man verstehen kann, was nicht auf Englisch daher kommt?
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Gehe in „Shop deiner Wahl“
Kaufe Buch „ Arduino für Anfänger „
Kaufe Buch „Avr für Dummies“
Lese die Tutorials für den AVR Atmega auf Micrikontroller. net

So wie wir alle das getan haben, in dieser oder anderer Reihenfolge.

Mehr kann man dazu erstmal nichts sagen,
Wenns dann klemmt, gerne nochmal hier fragen.
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Cubicany hat geschrieben: Fr 26. Nov 2021, 10:11 was nicht auf Englisch daher kommt?
Lern Englisch, sonst musst du garnicht erst anfagen mit Mikrocontrollern!
MSG
Beiträge: 2182
Registriert: Fr 9. Nov 2018, 23:24
Wohnort: Nähe Dieburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von MSG »

Cubicany hat geschrieben: Fr 26. Nov 2021, 10:11Gibt es da irgendwo was, was man verstehen kann, was nicht auf Englisch daher kommt?
Hier ein gutes Video von GreatScott https://www.youtube.com/watch?v=IdL0_ZJ7V2s ist zwar auf Englisch, aber er selbst ist Deutscher. Und er erklärt meiner Ansicht nach so, dass man es versteht.
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

Ak, ok, dann kann man damit schon was anfangen.

Noch was:

Das ganze Konstrukt soll später Wechselspannung schalten. Also einfach ein und aus.
Die Relais haben bereits Freilaufdioden und Kapazität auf der 5V DC Seite verbaut.

Nun ist es aber so, dass der Arduino selbst mit dem Delay Programm regelmäßig hängen bleibt.

Also muss die Wechselspannung irgendwie den Controller aus dem Takt bringen.

Wie kann man das am besten entstören?
Antworten