Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

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

Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

Finger hat geschrieben: Fr 23. Apr 2021, 21:11 Ansonsten sowas wie.n ULN2003 oder so als Treiber
Also mir als totaler Anfänger bei Schieberegistern usw. sagt das auch nicht viel.
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 »

Aber google kannste bedienen um mal ein Bild aufzurufen was der IC kann?
Benutzeravatar
barclay66
Beiträge: 1066
Registriert: Di 13. Aug 2013, 04:12
Wohnort: im Speckgürtel Münchens

Re: Der AVR-/ARDUINO-Faden

Beitrag von barclay66 »

35mA pro Ausgang. aber alle Zusammen nicht mehr als 70mA. Du brauchst also eine Treiberstufe für die LEDs.
Unbenannt.JPG
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

Fritzler hat geschrieben: Fr 23. Apr 2021, 21:13 Aber google kannste bedienen um mal ein Bild aufzurufen was der IC kann?
Habe gerade gesehen, dass das der iC ist, der auf dem Motortreiber von Arduino Lernset drauf sitzt.

Wie verbinde ich den denn am besten mit den vorhandenen Register?

Da gibt es offenbar verschiedene Arten.
Benutzeravatar
Bastelbruder
Beiträge: 11481
Registriert: Mi 14. Aug 2013, 18:28

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bastelbruder »

Das steht in dem Datenblatt auch nicht drin.
Da muß man das übergeordnete Datenblatt der HC-Familie konsultieren.
Ich denke daß 20 mA realisierbar sind, das kommt aber auch auf die Versorgungsspannung :?: an.
MSG
Beiträge: 2182
Registriert: Fr 9. Nov 2018, 23:24
Wohnort: Nähe Dieburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von MSG »

Wald und Wiesentransistor und Widerstand an das Schieberegister hängen?
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

Das gebe ich mir mal morgen in aller Ruhe.

Heute kommt da nichts mehr bei rum.
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

Ich habe diesen Plan hervorgetan, denn offenbar hat das schon mal wer gebaut:
LED.JPG
Abgesehen von der Schnittstelle zum Controller sieht man ja gut, wie Register und ULN2003A verbunden sind.

Und das man eben den GND schaltet anstelle der Versorgung.

Ich tu mich nur etwas schwer, wie herum die ICs gedreht sind.

Die haben ja so eine Kerbe an einem Ende. Zeigt die nach oben oder unten?

Gibt es da Standards bei so Schaltplänen?

Als Betriebstechniker lernen wir das leider nicht so im Detail.
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

https://en.wikipedia.org/wiki/ULN2003A
notfalls wüsste das dabla sowas.
Benutzeravatar
gafu
Beiträge: 6376
Registriert: Mi 14. Aug 2013, 20:56
Wohnort: nahe Jena
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von gafu »

das da an jedem anschluss zahlen stehen, hast du wohl noch nicht bemerkt.
Benutzeravatar
Cubicany
Beiträge: 3543
Registriert: Sa 15. Feb 2020, 17:48
Wohnort: Soest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Cubicany »

gafu hat geschrieben: Sa 24. Apr 2021, 12:10 das da an jedem anschluss zahlen stehen, hast du wohl noch nicht bemerkt.
Habe ich heute auch gesehen.

Gestern und heute früh hatte ich nur vom Schmierfon geschrieben.

Da sah man keine Zahlen dran stehen.
Benutzeravatar
Weisskeinen
Beiträge: 3942
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

Das Schaltsymbol von ICs kann die Pins wild durcheinander gewürfelt haben, so wie's am besten passt. IC's (also die physischen Bauteile) im DIL-Gehäuse haben auf einer Schmalseite eine Kerbe, ist die oben, ist links davon Pin Nr. 1. Gezählt wird gegen den Uhrzeigersinn. Häufig ist Pin 1 auch noch mal mit einem Punkt gekennzeichnet, aber bei weitem nicht immer.
Übrigens gibt es auch Schieberegister aus dem Automotive-Bereich, die mehr Strom treiben können. Die stecken in Armaturenbrettern drin...
berferd
Beiträge: 1327
Registriert: Mi 3. Apr 2019, 23:45

Re: Der AVR-/ARDUINO-Faden

Beitrag von berferd »

Hat von euch jemand Erfahrung mit Programmierung von TPI-Programmierung von Attinys (zB den Attiny5) unter Linux?
Habe mal recherchiert und tendierte zum Diamex ALL AVR, allerdings scheint das unter Linux Probleme zu machen, offiziell wird nur Windows unterstützt. Avrdude kann es angeblich, allerdings nicht unter allen Linux-Versionen und nicht mit allen Diamex-Firmwareversionen, es gibt aber angeblich Workarounds unter Linux, die aber wieder nicht für alle funktionieren, etc... kurzum: Chaos!
Wer hat Empfehlungen?
Benutzeravatar
Torpert
Beiträge: 1415
Registriert: Mo 12. Aug 2013, 22:40
Wohnort: Saarland
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Torpert »

Ich habe einen Schrittmotor über einen Schrittmotortreiber (unbekannter Typ) am atmega2560 angeschlossen und will den immer laufen lassen, wenn ein Taster gedrückt ist. Mein Programm sieht so aus:

Code: Alles auswählen

#include <avr/io.h>
#include <util/delay.h>

// Stepper_E
#define	stepPin PA4            //Define Step pin
#define dirPin PA6             //Define Direction pin
#define enablePin PA2          //Define Enable pin
#define controlSwitch PE4      //Define Control Switch pin (D2)

int main(void)
{

    DDRA |= (1<<stepPin)|(1<<dirPin)|(1<<enablePin);     // Configure ports as output	 
    PORTA &= ~(1<<enablePin);                            // Enable driver
	PORTA &= ~(1<<dirPin);                //Make PORTA6 low to rotate motor in counter clockwise direction
	
	DDRE &= ~(1 << PE4);      // PE4 as input
	PORTE |= (1 << PE4);      // activate internal pullup
	
    while (1) 
    {
	    PORTA &= ~(1<<dirPin);                //Make PORTA6 low to rotate motor in counter clockwise direction

		if(!(PINE & (1<<PE4)) == 1) //If switch is pressed
           {
		      PORTA &= ~(1<<enablePin);
		      PORTA |=(1<<stepPin);
		      _delay_us(200);
		      PORTA &=~(1<<stepPin);
		      _delay_us(200);
		   }
		else
		   {
		      PORTA |=(1<<enablePin);
		   }
    }
}
Das Programm funktioniert. Was ich nicht verstehe, ist:

wenn ich die erste Zeile im while(1) weglasse [PORTA &= ~(1<<dirPin);], dann verhält das System sich nicht so, wie ich es erwarte. Wenn der Controller eine längere Zeit angeschaltet ist, vergisst er offenbar seine Drehrichtung und zappelt beim Betätigen des Tasters nur noch rum. Wenn ich das Richtungsregisters des Treibers permanent neu setze, funktioniert alles.

Vergisst so ein Microcontroller seine Portwerte mit der Zeit? Oder was stimmt hier nicht?
Anse
Beiträge: 2278
Registriert: Mo 12. Aug 2013, 21:30
Wohnort: Bühl (Baden)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Anse »

Vergisst so ein Microcontroller seine Portwerte mit der Zeit? Oder was stimmt hier nicht?
Also ich sehe auf die Schnelle nichts. Das Einzige was sein könnte:

Code: Alles auswählen

#define	stepPin PA4            //Define Step pin
#define dirPin PA6             //Define Direction pin
#define enablePin PA2          //Define Enable pin
#define controlSwitch PE4      //Define Control Switch pin (D2)
Verwende mal statt den Konstanten PA6, PA2 usw. die "richtigen" Pin Nummern. Also 6, 2 usw. Ich weiß jetzt nicht auswendig, wie die Konstanten definiert sind.
[Hier stand Blödsinn]

Der geänderte Code:

Code: Alles auswählen

#include <avr/io.h>
#include <util/delay.h>

// Stepper_E
#define	stepPin 4            //Define Step pin
#define dirPin 6             //Define Direction pin
#define enablePin 2          //Define Enable pin
#define controlSwitch 4      //Define Control Switch pin (D2)

int main(void)
{

    DDRA |= (1<<stepPin)|(1<<dirPin)|(1<<enablePin);     // Configure ports as output	 
    PORTA &= ~(1<<enablePin);                            // Enable driver
	PORTA &= ~(1<<dirPin);                //Make PORTA6 low to rotate motor in counter clockwise direction
	
	DDRE &= ~(1 << 4);      // PE4 as input
	PORTE |= (1 << 4);      // activate internal pullup
	
    while (1) 
    {
	    PORTA &= ~(1<<dirPin);                //Make PORTA6 low to rotate motor in counter clockwise direction

		if(!(PINE & (1<<4)) == 1) //If switch is pressed
           {
		      PORTA &= ~(1<<enablePin);
		      PORTA |=(1<<stepPin);
		      _delay_us(200);
		      PORTA &=~(1<<stepPin);
		      _delay_us(200);
		   }
		else
		   {
		      PORTA |=(1<<enablePin);
		   }
    }
}
Benutzeravatar
sukram
Beiträge: 3063
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

Aufpassen, control und step pin landen auf dem gleichen Ausgang, wenn dort die 4 steht. Arduino hat da so eine (ich finde ungeschickte) Übersetzung zwischen Platinenpin (fortlaufend nummeriert) und Controllerpin (in 8er Gruppern).
Benutzeravatar
Torpert
Beiträge: 1415
Registriert: Mo 12. Aug 2013, 22:40
Wohnort: Saarland
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Torpert »

Das stimmt schon so. Die 4 vom ControlSwitch wird an PORTE geschickt, die 4 vom StepPin an PORTA.

Ist auch nix mit Arduino. Ich hätte vielleicht gleich dazuschreiben sollen: Das ist ein nacktes Programm, compiliert per Kommandozeile unter avr-gcc. Ich binde keine Arduino Libraries ein und nutze auch keine Arduino IDE.

Das Programm funktioniert ja auch - egal, ob ich die Konstanten durch die Zahlenwerte ersetze oder nicht. Wenn da ein Fehler drin wäre, hätte es ja mit der Konstanten-Version schon nicht funktionieren dürfen.

Die ungeklärte Frage ist: Was passiert mit dem dirPin, wenn ich den nur beim Programmstart einmalig setze? Der geht offenbar irgendwann (Zeitraum etwa 1 Stunde, habe die Zeit aber nicht gemessen) verloren und der Schrittmotortreiber hat einen instabilen Wert. Als Notbehelf setze ich den Ausgang in der Schleife bei jedem Durchgang. Das ist garantiert ineffizient und ich würde gerne den Fehler verstehen, damit ich eine bessere Lösung einbauen kann.
Benutzeravatar
Finger
Administrator
Beiträge: 7392
Registriert: Di 12. Jun 2012, 20:16
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Finger »

Kann es sein das der Pin hochohmig ist? Dann wäre das Ergebnis eher Zufall was da rauskommt. Ich hab das Datenblatt grad nicht vor Augen, ist da noch andere Peripherie dran?
Wie sieht der Pegel auf dem Pin aus? Kannst du den z.B. mit 470 Ohm gegen GND oder VCC verziehen?
sysconsol
Beiträge: 4059
Registriert: Fr 8. Jul 2016, 17:22

Re: Der AVR-/ARDUINO-Faden

Beitrag von sysconsol »

Torpert hat geschrieben: Mo 3. Mai 2021, 16:20 Die ungeklärte Frage ist: Was passiert mit dem dirPin, wenn ich den nur beim Programmstart einmalig setze?
Wenn der nicht wieder geändert wird, bleibt der so.
Das ist zumindest der Sinn dahinter.

Wenn du vermutest, dass es daran liegt, dann frage doch regelmäßig ab und gib den Zustand zum Debuggen aus.
Seriell oder via anderem Pin.

Sollte der Compiler da etwas wegoptimieren? :?

Ist der Pin am IC defekt?
Zumindest beim PIC sterben die immer schön portweise... :oops:
Benutzeravatar
sukram
Beiträge: 3063
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

Setzt du die DDRx Register auch passend? (Blöde Frage, passiert aber gerne mal)
Benutzeravatar
Torpert
Beiträge: 1415
Registriert: Mo 12. Aug 2013, 22:40
Wohnort: Saarland
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Torpert »

Ich habe von euren Ideen als erste die Überwachung des Pin implementiert (an den Hardware-Ausgang komme ich nur schlecht ran, das läuft auf einem ausrangierten Board vom 3D-Drucker. Da sind Mikrocontroller und Stepper driver direkt verdrahtet).

Jetzt bin ich verwirrt - ich bekomme den Fehler nicht mehr reproduziert :o

Einerseits gut, wenn alles funktioniert. Andererseits wüsste ich schon gerne, was falsch war :?

Der Pin ist Solo, hat keine weitere Funktion. Aber ins Datenblatt gucken ist nie verkehrt: Als ich dort nach dem Pin gesehen habe, bin ich über diesen Passus gestolpert:

The Port A pins are tri-stated when a reset condition becomes active, even if the clock is not running.

Was ist denn mit einer "reset condition" gemeint?
berferd
Beiträge: 1327
Registriert: Mi 3. Apr 2019, 23:45

Re: Der AVR-/ARDUINO-Faden

Beitrag von berferd »

reset condition: Ich würde sagen: Reset-Pin low, oder Betriebsspannung zu niedrig (Brownout).
Prinzipiell könnte schon sein, dass Dein uC sich aufgrund EMV, Störungen in der Versorgung (Zuschalten großer Lasten?) o.ä. ab und zu verschluckt und in den Reset geht. Allerdings sollte er sich dann ja sofort wieder fangen nach dem Reboot?
Benutzeravatar
Torpert
Beiträge: 1415
Registriert: Mo 12. Aug 2013, 22:40
Wohnort: Saarland
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Torpert »

berferd hat geschrieben: Di 4. Mai 2021, 13:51 reset condition: Ich würde sagen: Reset-Pin low, oder Betriebsspannung zu niedrig (Brownout).
Prinzipiell könnte schon sein, dass Dein uC sich aufgrund EMV, Störungen in der Versorgung (Zuschalten großer Lasten?) o.ä. ab und zu verschluckt und in den Reset geht. Allerdings sollte er sich dann ja sofort wieder fangen nach dem Reboot?
So hätte ich auch getippt. Wobei es schon sein könnte, dass ich bei den ersten Probeläufen mit den Timings für den Stepper so weit daneben gelegen habe, dass der den Motortreiber überfordert hat. Wenn es möglich ist, dass das Board eine "reset condition" erzeugt, ohne mein Programm wieder von vorne zu starten, könnte das den Fehler erklären.

Ich versuche mal, das zu reproduzieren.
Benutzeravatar
barclay66
Beiträge: 1066
Registriert: Di 13. Aug 2013, 04:12
Wohnort: im Speckgürtel Münchens

Re: Der AVR-/ARDUINO-Faden

Beitrag von barclay66 »

Falls Du einen Watchdog-Timer aktiviert haben solltest und den nicht rechtzeitig gefüttert bekommst, würde es auch immer mal wieder Resets geben...
Anse
Beiträge: 2278
Registriert: Mo 12. Aug 2013, 21:30
Wohnort: Bühl (Baden)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Anse »

MCUCR Auslesen und die Reset Source auslesen. Hat bei mir schon einige Mal Aufklärung gebracht über ominöse Resets.
Benutzeravatar
Torpert
Beiträge: 1415
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: 1415
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: 1415
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: 1415
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: 11481
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: 1415
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
Antworten