Seite 24 von 31

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 23. Apr 2021, 21:13
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 23. Apr 2021, 21:13
von Fritzler
Aber google kannste bedienen um mal ein Bild aufzurufen was der IC kann?

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 23. Apr 2021, 21:16
von barclay66
35mA pro Ausgang. aber alle Zusammen nicht mehr als 70mA. Du brauchst also eine Treiberstufe für die LEDs.
Unbenannt.JPG

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 23. Apr 2021, 21:17
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 23. Apr 2021, 21:18
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 23. Apr 2021, 21:19
von MSG
Wald und Wiesentransistor und Widerstand an das Schieberegister hängen?

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 23. Apr 2021, 21:27
von Cubicany
Das gebe ich mir mal morgen in aller Ruhe.

Heute kommt da nichts mehr bei rum.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Sa 24. Apr 2021, 10:32
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Sa 24. Apr 2021, 10:35
von ch_ris
https://en.wikipedia.org/wiki/ULN2003A
notfalls wüsste das dabla sowas.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Sa 24. Apr 2021, 12:10
von gafu
das da an jedem anschluss zahlen stehen, hast du wohl noch nicht bemerkt.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Sa 24. Apr 2021, 13:13
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 25. Apr 2021, 22:15
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...

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 2. Mai 2021, 16:25
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?

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 2. Mai 2021, 20:05
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?

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 2. Mai 2021, 22:30
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);
		   }
    }
}

Re: Der AVR-/ARDUINO-Faden

Verfasst: Mo 3. Mai 2021, 14:22
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).

Re: Der AVR-/ARDUINO-Faden

Verfasst: Mo 3. Mai 2021, 16:20
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Mo 3. Mai 2021, 16:36
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?

Re: Der AVR-/ARDUINO-Faden

Verfasst: Mo 3. Mai 2021, 17:03
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:

Re: Der AVR-/ARDUINO-Faden

Verfasst: Mo 3. Mai 2021, 17:23
von sukram
Setzt du die DDRx Register auch passend? (Blöde Frage, passiert aber gerne mal)

Re: Der AVR-/ARDUINO-Faden

Verfasst: Di 4. Mai 2021, 13:34
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?

Re: Der AVR-/ARDUINO-Faden

Verfasst: Di 4. Mai 2021, 13:51
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?

Re: Der AVR-/ARDUINO-Faden

Verfasst: Di 4. Mai 2021, 14:09
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Di 4. Mai 2021, 16:50
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...

Re: Der AVR-/ARDUINO-Faden

Verfasst: Di 4. Mai 2021, 19:28
von Anse
MCUCR Auslesen und die Reset Source auslesen. Hat bei mir schon einige Mal Aufklärung gebracht über ominöse Resets.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 7. Mai 2021, 11:52
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 :?

Re: Der AVR-/ARDUINO-Faden

Verfasst: Do 13. Mai 2021, 09:32
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?

Re: Der AVR-/ARDUINO-Faden

Verfasst: Do 13. Mai 2021, 09:54
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Do 13. Mai 2021, 10:32
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 :)

Logic Level Shifter für 12 V?

Verfasst: So 11. Jul 2021, 12:22
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 3. Okt 2021, 15:14
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 3. Okt 2021, 15:34
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 3. Okt 2021, 15:34
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 3. Okt 2021, 16:11
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
}

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 3. Okt 2021, 17:57
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
      }

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 3. Okt 2021, 18:17
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....

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 3. Okt 2021, 21:36
von Hightech
Bin grad hier drüber gestolpert:
Industrie Arduino
https://www.controllino.shop/c/shop

Re: Der AVR-/ARDUINO-Faden

Verfasst: Do 11. Nov 2021, 16:46
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Do 11. Nov 2021, 23:38
von Bastelbruder
Der Digitalismus sollte sich von Fluktuationen der Betriebsspannung nicht beeinducken lassen. Garnicht. Niemals!

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 12. Nov 2021, 08:21
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 12. Nov 2021, 10:00
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 12. Nov 2021, 11:16
von Weisskeinen
Mal für Doofe: was tut es und was hat die Änderung für Auswirkungen?

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 12. Nov 2021, 11:24
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 14. Nov 2021, 18:49
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 14. Nov 2021, 19:17
von Hightech
Fehlt der Bootloader vielleicht?

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 14. Nov 2021, 19:21
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 14. Nov 2021, 19:24
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 :-)

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 14. Nov 2021, 19:28
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 14. Nov 2021, 19:29
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 14. Nov 2021, 19:40
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