Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

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

ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

nee, ist ein schaltassistent aka kupplungsloses schalten.
danke, ich guck mir das am pc morgen mal an.
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

hab noch andere Änderungen drin die erst mal getestet werden müssen,
so ähnlich könnte ich mir das aber zukünftig vorstellen.
Alexander470815 hat geschrieben: Fr 1. Jul 2022, 20:07 Ein Zählwert von 1500 wären 10.000 U/min
Ein Zählwert von 1501 wären 9.993 U/min
Bei 10.000 U/min hätte man somit noch eine Auflösung von 7 U/min.

Reicht das nicht könnte man den Prescaler ja noch schneller wählen.
eine Auflösung von ~250U reicht hier technisch imho.
viel hilft natürlich viel, auch bei der zeitlichen Auflösung.

hab's mal überschlagen, der zu erwartende Drehzahl Abfall/Anstieg entspricht etwa meiner rpm Auflösung.
ich sag mal bis 2000 Umin pro sekunde, also etwa die gleiche Größenordnung.
Damit ist das ganze aber möglicherweise grenzwertig bzw. ausgereizt.
ich behalte das mal im Hinterkopf, danke nochmal.
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 »

ich hab das an meiner Bohrmaschine mit ein mal

attachInterrupt(digitalPinToInterrupt(PinA), Berechnung, FALLING);

im Setup und dann

void Berechnung () {
Zeit_Gemessen = millis() - Letzte_Messung; // Zeit in ms
Letzte_Messung = millis();
Drehzahl = 60000 / Zeit_Gemessen; // Aktuelle Drehzahl
}

Berechnung eines Mittelwerts dann in der Ausgabe. Funktioniert wunderbar. Das ist ja das, was Alexander vorgeschlagen hatte. Die erste Iteration hatte bei mir auch erst Pulse in einem festen Zeitfenster gezählt und umgerechnet, ist aber iwie nicht so gut gelaufen. Hatte auch probleme wg digiSpark/Attiny85 und dem Bootloader und hab ewig pins vertauschen müssen, bis es irgendwann mal gelaufen ist. Wird nicht mehr angefasst. ;)
MSG
Beiträge: 2182
Registriert: Fr 9. Nov 2018, 23:24
Wohnort: Nähe Dieburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von MSG »

Was mache ich falsch (ESP32)?

Code: Alles auswählen

void S(String text){
  if ( settings.debug == true ) {
    Serial.print(text);
  }
}

S("---");
S("a");
S("b");
S("---");
S("a" + "b");
S("---");

src/main.cpp:111:11: error: invalid operands of types 'const char [2]' and 'const char [2]' to binary 'operator+'
   S("a" + "b");
           ^
Ich dachte beim Arduino ist alles, was zwischen doppelten Anführungszeichen steht ein String, dann sollte man den doch auch verknüpfen können? Aber der Fehlermeldung nach sind das wohl zwei char Arrays ....
Erwartet hätte ich, dass da
---ab---ab---
rauskommt.

Ziel des ganzen soll eigentlich sein, einfach debugging-Meldungen auszugeben mit so etwas
S("blablubber ist: " + blablubber + "\n");
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

nee, geht nicht. in JS ja. glaub ich.
aber type Nazis wie c , java lassen das nicht zu. oder? nochmal einklammern?
virtexultra
Beiträge: 127
Registriert: So 9. Dez 2018, 11:30

Re: Der AVR-/ARDUINO-Faden

Beitrag von virtexultra »

Nein, die Annahme mit den Anführungszeichen ist falsch. Das ist erst mal ein const char*. Dieser wird nur implizit in einen String umgewandelt da die Funktion S einen String erwartet und die Klasse String einen passenden Konstruktor bereitstellt.

Als einfache Abhilfe hier, sollte man das erste Element explizit in ein String Objekt wandeln können.

Code: Alles auswählen

S(String("a") + "b");
Dann wird nicht mehr probiert den operator+ auf zwei const char* auszuführen sondern auf ein String Objekt und einen const char*. Hierfür bietet die Klasse String eine geeignete Funktion und das concat kann ausgeführt werden.
MSG
Beiträge: 2182
Registriert: Fr 9. Nov 2018, 23:24
Wohnort: Nähe Dieburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von MSG »

ch_ris hat geschrieben: Mi 13. Jul 2022, 16:39 nee, geht nicht. in JS ja. glaub ich.
aber type Nazis wie c , java lassen das nicht zu. oder? nochmal einklammern?
Naja in mindestens PERL, PHP würde es gehen, JS meineswissens auch.

Aber selbst in ABAP, das typisiert ist, geht das. Hier werden Zeichenketten in ' eingeschlossen und Strings in |:

Code: Alles auswählen

data: lv_zahl1 type i default 4,
      lv_zahl2 type p length 5 decimals 2,
      lv_bla type c length 3 default 'bla'.

form S using iv_text type string.
  write: /, iv_text.
endform.

perform S using |Hier steht jetzt fließtext und die Zahl 1 ist { lv_zahl1 } und Zahl 2 ist { lv_zahl2 } und bla ist { lv_bla }.|.
virtexultra hat geschrieben: Mi 13. Jul 2022, 16:46 Nein, die Annahme mit den Anführungszeichen ist falsch. Das ist erst mal ein const char*. Dieser wird nur implizit in einen String umgewandelt da die Funktion S einen String erwartet und die Klasse String einen passenden Konstruktor bereitstellt.

Als einfache Abhilfe hier, sollte man das erste Element explizit in ein String Objekt wandeln können.

Code: Alles auswählen

S(String("a") + "b");
Dann wird nicht mehr probiert den operator+ auf zwei const char* auszuführen sondern auf ein String Objekt und einen const char*. Hierfür bietet die Klasse String eine geeignete Funktion und das concat kann ausgeführt werden.
Danke für die ausführliche Erklärung virtexultra. So ist das verständlich warum das so ist. Die Idee, den linken Operanden erst mal zum String zu machen funktioniert einwandfrei. Deine Lösung compiliert sogar mit etwas anspruchsvolleren Aufrufen:

Code: Alles auswählen

S(String("a") + "b" + 5 + 'o' + String(1.23456, 2) + "\n");
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

ah! wieder was gelernt.
Das mit den Nazis bitte humorig verstehen, hat auch seine Vorteile.

ich brauche mal einen watchdog im Nano.
bin mir nicht sicher ob ich den Kommentar in der wdt.h richtig verstehe.
ist's so richtig?:

Code: Alles auswählen

void setup() {
	MCUSR = 0;
	wdt_disable();
	....zeug
	wdt_enable(WDTO_1S);
	}
	loop: wdt_reset()
	
\code
#include <stdint.h>
#include <avr/wdt.h>

uint8_t mcusr_mirror __attribute__ ((section (".noinit")));

void get_mcusr(void) \
__attribute__((naked)) \
__attribute__((section(".init3")));
void get_mcusr(void)
{
mcusr_mirror = MCUSR;
MCUSR = 0;
wdt_disable();
}
\endcode

Saving the value of MCUSR in \c mcusr_mirror is only needed if the
application later wants to examine the reset source, but in particular,
clearing the watchdog reset flag before disabling the
watchdog is required, according to the datasheet.
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Für den watchdog noch der Hinweis, dass dieser mit dem alten Bootloader, der auf den ganzen Chinaklonen der Nanos drauf ist, nicht funktioniert.
Also zuerst den neuen Bootloader oder den vom UNO oder einen ganz anderen passenden draufpacken.
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

verdammt.
wie äussert sich das? geht einfach nicht?
irgendwas las ich das man den quasi bricken könnte und nur noch per isp rankommt.
Benutzeravatar
Alexander470815
Beiträge: 2371
Registriert: So 11. Aug 2013, 15:42
Wohnort: D:\Hessen\Gießen

Re: Der AVR-/ARDUINO-Faden

Beitrag von Alexander470815 »

Naja ein USBasp kostet doch nichts, einfach darüber programmieren und das Bootloader Problem erübrigt sich.
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Und wenn kein usbasp zur hand ist kann man einfach einen zweiten Arduino als ISP verwenden, das hat man ja meistens rumliegen. Sann ist das eine Sache von wenigen Minuten.
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

ja klar, muss man halt auf dem schirm haben. und grad den fraglichen uploade ich mit dem phone. wenn der dann erst mal tot ist geht im Feld nix mehr.
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

ich muss noch mal nach-haken, hab jetzt so getan wie im Kommentar beschrieben:

Code: Alles auswählen

 #include <avr/wdt.h>

    uint8_t mcusr_mirror __attribute__ ((section (".noinit")));

    void get_mcusr(void) \
      __attribute__((naked)) \
      __attribute__((section(".init3")));
    void get_mcusr(void)
    {
      mcusr_mirror = MCUSR;
      MCUSR = 0;
      wdt_disable();
    }
damit sollte ja nur noch ein wdt_enable(x); am ende der setup() nötig sein.
wenn ich jetzt in setup mcusr_mirror ins eeprom logge und dann später ausgebe (Serial.print(EEPROM.read(var), 10);):
reset knopp oder per konsole =121 (0b 01111001)
kabel ziehen=91 (0b 01011011)

wenn ich mcusr_mirror nach dem loggen auf null setzte:
reset knopp oder per konsole =0
kabel ziehen=121

:?:
wieso macht das einen unterschied?
was bedeutet das überhaupt, sollte nicht 0000xxxx rauskommen?

oder 123 oder 89 kommt da raus, auf nix ist verlass :cry:
(edit, ach verdammt, das könnte eine eeprom schreib/lese schwäche sein, hängt nur am usb strom.
aber der oben beschriebene unterschied ist ja nicht nur ein falsches bit)
Benutzeravatar
gafu
Beiträge: 6376
Registriert: Mi 14. Aug 2013, 20:56
Wohnort: nahe Jena
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von gafu »

Später Gast hat geschrieben: Mo 4. Jul 2022, 11:04 Hatte auch probleme wg digiSpark/Attiny85 und dem Bootloader und hab ewig pins vertauschen müssen, bis es irgendwann mal gelaufen ist. Wird nicht mehr angefasst. ;)
Ich hatte mich gefragt, ob nur ich "Pech" mit Openhardware habe, letztes Problem digisparks.
Nach so im Mittel 10-15 programmiervorgängen schreibt sich der bootloader scheinbar seinen eigenen Speicher kaputt, und programmieren über USB geht nimmer.
Ich hatte 5 davon, zuletzt waren vier davon tot.

An einen toten hab ich ICSP Kabel angelötet und per usbasp dann ohne bootloader direkt aufgespielt, das ging sofort. Geht aber nicht bei den original digistump, wo per Fuses der reset abgeschaltet ist, aber ich hatte eh keine original.

Einer ist gestorben, als ich den an eine usb-verlangerung mit Wackelkontakt / kein Kontakt auf den stromleitungen gesteckt hab, die wird dann noch ausgesondert.

Ich bin jetzt so auf dem Trip, da den USB Kontakte Teil abzusägen und die dann von dem unzuverlässigen bootloader zu befreien
Das der beim Schreiben die geschriebenen Daten nicht zur Kontrolle zurückliest, ist schon scheiße genug, aber wenn der sich regelmäßig selber abschießt, das geht gar nicht.

Müll eigentlich.
Leider sind atmel MCU gerade Goldstaub geworden irgendwie, die STM32 und ESP32 dagegen preislich noch normal.
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

gafu hat geschrieben: Mo 18. Jul 2022, 15:41 die STM32 und ESP32 dagegen preislich noch normal.
In welchem Universum? :D
Die ganze Industrie geiert gerade nach STM32, nichts lieferbar.
Die Bluepill Boards mit STM32F103 kosten aus China 7 €, die waren mal bei unter einem Euro pro Stück. Und mit hoher Wahrscheinlichkeit bekommt man da mehr oder weniger gute Klone, ich hatte da mal ein Exemplar das soweit funktioniert, aber der UART hat sich immer mal wieder komisch verhalten, bei einem originalen STM32 ging alles einwandfrei.
Benutzeravatar
gafu
Beiträge: 6376
Registriert: Mi 14. Aug 2013, 20:56
Wohnort: nahe Jena
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von gafu »

Ich hatte nur kurz bei AliExpress geguckt, da waren die STM32 Boards (vergleichbar zu arduino Mini oder sowas) bei 1,90 herum.
Und die mega328 bei 7 usd
Jannyboy
Beiträge: 1406
Registriert: So 11. Aug 2013, 14:49
Wohnort: Kreis Augsburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Jannyboy »

gafu hat geschrieben: Di 19. Jul 2022, 21:57 Ich hatte nur kurz bei AliExpress geguckt, da waren die STM32 Boards (vergleichbar zu arduino Mini oder sowas) bei 1,90 herum.
Und die mega328 bei 7 usd
Drei Board bei Ali bekommst du.
Willst du aber 200-300 Stück für Nullserie haben muss man schon stückeln mit verschiedenen Ratings und Ausbaustufen. 10k Stück für die Serie kannst gleich vergessen.

Grüße Jan
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

Hab probiert MCUSR mit externer besaftung zu lesen.
ich kann kein System entdecken. es kommt zwar nicht jedes Mal was anderes raus,
zb. bei Reset per Konsole 5x hintereinander 0,
nach dem nächsten Kaltstart und erneuten Konsole Reset aber wieder mehrfach was anderes.
war immer 0 oder die ersten 4 bits, die 0 sein sollten, waren auch beteiligt.

Brown Out Detection?
ist standardmäßig off glaub ich.
sollte doch aber bei einem Reset nix ausmachen?

oder das ist einfach nicht zu gebrauchen.

EDIT
der bootloader könnte schuld sein.
https://www.idogendel.com/en/archives/623
je nachdem welcher, löscht der mcusr.
0 scheint also ein korrektes Ergebnis.
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

weitere versuche wurden durch mein isp adapter eingebremst.
bastelstunde.
scheint sich aber gelohnt zu haben, erste versuch hat geklappt.
Dateianhänge
noex_153.jpg
noex_153.jpg (10.21 KiB) 1394 mal betrachtet
xanakind
Beiträge: 12538
Registriert: So 11. Aug 2013, 21:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von xanakind »

Kurze Frage mal zu einem anderen Controller:
STM32 und der STM32 Cube Programmer.
Ich will ja auf meinen DPS5005 Modulen eine andere Firmware installieren:
https://hackaday.com/2022/01/22/another ... -firmware/
Eine Anleitung für dummies wie mich gibt es hier:
https://profimaxblog.ru/dps_fw_flashing/
Leider hängt es bei mir an grundlegenden Dingen:
Ich kann keine Verbindung aufbauen:
Zwischenablage02.jpg
Im Gerätemanager wird der Programmer (3€ China-Clone) angezeigt und wird wohl korrekt erkannt.
Ein Firmwareupdate über den CubeProgrammer hat scheinbar auch funktioniert.
Drücke ich auf "Connect" passiert nichts
Egal was ich da einstelle.
Nichtmal eine Fehlermeldung erscheint :(

Ich werde das morgen mal auf einem anderen Rechner testen, ich vermute das ist wieder mal so ein typisches Windows-Ding.
Der Rechner hier war jetzt mal 5 Tage aus und ohne Strom. Geht das W-Lan nicht mehr richtig. "Keine Internetverbindung" mit dem Laptop ging es aber :roll:
bastelheini
Beiträge: 1663
Registriert: So 11. Aug 2013, 13:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von bastelheini »

nur überflogen aber bei dir ist JTAG statt SWD eingestellt... Absicht?
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 »

Jap, JTAG ist falsch, die STM32 sind meist per SWD programmiert, weil das viel weniger Pins brauch.

Und nimm nicht diesen sch**ss Cube Programmer das ist völlig dumme klickibunti SW ohne ordentliche Fehlermeldungen.
Der Vorgänger ist da besser: https://www.st.com/en/development-tools ... nk004.html
(ST Link Utility)
poolizei
Beiträge: 110
Registriert: Mi 8. Feb 2017, 00:16

Re: Der AVR-/ARDUINO-Faden

Beitrag von poolizei »

xanakind hat geschrieben: Mo 25. Jul 2022, 00:02 Ein Firmwareupdate über den CubeProgrammer hat scheinbar auch funktioniert.
Üblicherweise ist genau das daß Problem durch die FW Updates werden die China Klone unbrauchbar obwohl sie prinzipiell super laufen...

Mir auch passiert obwohl ich den Klon unwissentlich zum Original Preis erworben habe.
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 »

Falls das der Fall sein sollte kann es Xana ja zum Treffen mitbringen.
Dann komm ich mitm Programmer.
(Aber vorher Bescheid sagen, sonst nehm ich den nicht mit!)

Ein Adapter von ARM 20 pol JTAG (2,54mm) auf DPS5005 musste aber selber mitbringen:
Bild
Benötigt werden:
vtref an 3,3V
SWDIO, SWDCLK, GND, reset
xanakind
Beiträge: 12538
Registriert: So 11. Aug 2013, 21:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von xanakind »

Danke für die Info, also habe ich mir den mit dem FIrmwareupdate wohl gehimmelt :roll:
Ich werde später aber noch das ST Link utility testen, vielleicht geht es damit ja.
xanakind
Beiträge: 12538
Registriert: So 11. Aug 2013, 21:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von xanakind »

Fritzler hat geschrieben: Mo 25. Jul 2022, 07:53 Falls das der Fall sein sollte kann es Xana ja zum Treffen mitbringen.
Dann komm ich mitm Programmer.
(Aber vorher Bescheid sagen, sonst nehm ich den nicht mit!)

Ein Adapter von ARM 20 pol JTAG (2,54mm) auf DPS5005 musste aber selber mitbringen:
Bild
Benötigt werden:
vtref an 3,3V
SWDIO, SWDCLK, GND, reset
Verstehe ich das richtig:
Du kannst mit deinem Programmer die Firmware auf meinem China-Clone neu aufspielen?
Die 3 Drähte da dranfummeln sollte ich hinbekommen :lol:
Ich melde mich aber dann nochmals
xanakind
Beiträge: 12538
Registriert: So 11. Aug 2013, 21:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von xanakind »

Ha! mit dem alten ST Link Utility hat es auf anhieb (!) funktioniert:
1.jpg
Danke für die Hilfe! :)
So, jetzt noch die restlichen 6 Stück umprogrammieren.....
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 »

Oha, hochkant für mehr Packungsdichte oder was? :lol:

Wenn der alte ST Link geht, kannste den neuen damit ja nun auch coden.
Musst aber den Hardware Reset rausführen.
xanakind
Beiträge: 12538
Registriert: So 11. Aug 2013, 21:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von xanakind »

Hat völlig problemlos geklappt:
1.jpg
Die Firmware ist nun auf allen aufgespielt:
2.jpg
:D
jodurino
Beiträge: 2088
Registriert: So 17. Nov 2013, 20:43

Re: Der AVR-/ARDUINO-Faden

Beitrag von jodurino »

Moin

habe am Arduino UNO diese 5mm LEDs angeschlossen:
https://www.conrad.de/de/p/thomsen-led- ... 75784.html
mit SK6812 und auch nur 4 Stück.

die Idee kommt von hier:
https://funduino.de/nr-17-ws2812-neopixel

Code: Alles auswählen


#include <Adafruit_NeoPixel.h>
// die folgenden 3 Zeilen auszukommentieren bringt auch nix
#ifdef __AVR__
#include <avr/power.h> // Required for 16 MHz Adafruit Trinket
#endif
//

#define PIN        6 // Pin für die Datenleitung ob 9 oder 6 bedes probiert
#define NUMPIXELS 4 // Anzahl der WS2812 LEDs oder der NEOPIXEL

Adafruit_NeoPixel pixels(NUMPIXELS, PIN, NEO_GRB + NEO_KHZ800);

void setup() 
{
  pixels.begin(); // Initialisierung der LEDs
}

void loop() {
	 pixels.clear(); // Deaktivieren aller LEDs
    pixels.setPixelColor(3, pixels.Color(0, 150, 0));
    pixels.show();   // Senden der aktualisierten Daten an die WS2812 LEDs
    delay(500);
    pixels.clear(); // Deaktivieren aller LEDs
    pixels.setPixelColor(3, pixels.Color(150, 0, 0));
    pixels.show();   // Senden der aktualisierten Daten an die WS2812 LEDs
    delay(500);
    pixels.clear(); // Deaktivieren aller LEDs
    pixels.setPixelColor(3, pixels.Color(0, 0, 150));
    pixels.show();   // Senden der aktualisierten Daten an die WS2812 LEDs
    delay(500);
    pixels.clear(); // Deaktivieren aller LEDs
	pixels.setPixelColor(3, pixels.Color(0, 150, 150));
    pixels.show();   // Senden der aktualisierten Daten an die WS2812 LEDs
    delay(500);
}
eigentlich müsste eine LED die Farbe wechseln, macht es aber nicht, es wechseln 2 oder 3 verschiedene die Farben.
DIN und DO sind bei allen richtig belegt, habe mal zum Test an dem ersten DIN einen 470 Ohm Widerstand eingebaut hat es aber auch nicht gebracht

Wenn ich die erste LED Anspreche geht es.
Achso alle Verbindungen an den LEDs sind gelötet aso nix Steckbrett

Muss ich bei den SK6812 noch einen extra Tanz aufführen?

EDIT sagt: Arduino Mega zum Probieren genommen, gleicher Effekt

cu
jodurino
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 »

Du hast RGBW LED, deine Befehle hauen aber nur RGB Daten raus, deine Anleitung spricht von "Im Setup wir der Befehl „NEO_GRB“ gegen „NEO_GRBW“ ausgetauscht." und " In dem Befehl wird eine vierte Zahlenposition ergänzt. pixels.setPixelColor(x,pixels.Color(255,0,0,0))=Rot"

probier das mal aus
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Wie kommst du darauf, dass das RGBW LEDs sind?
Sowohl die Artikelbeschreibung als auch das Datenblatt von diesen 5 mm LEDs spricht nur von RGB.

Die Neopixel sind recht empfindlich was die Spannungsversorgung angeht, die typischen LED-Streifen oder kleinen Platinchen haben immer einen 100 nF Kondensator direkt an der LED über die Spannungsversorgung. Pack doch auch mal an deine LEDs je einen 100 nF Kondensator, vielleicht ändert das was?
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: Fr 5. Aug 2022, 23:49 Wie kommst du darauf, dass das RGBW LEDs sind?
Hirnfurz :oops: Hatte bisher nur die WS2812 und die haben nur RGB und mal nach den SK6812 gegoogelt, und da halt RGBW Suchergebnisse gefunden. Beim verlinkten Angebot übersehen, dass die nur RGB sind. Kann ja aber immernoch sein, dass der Chip ein Oktett mehr haben will, selbst wenn er W nicht ausgeben kann oder halt nichts angeschlossen ist.
Jannyboy
Beiträge: 1406
Registriert: So 11. Aug 2013, 14:49
Wohnort: Kreis Augsburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Jannyboy »

Später Gast hat geschrieben: Sa 6. Aug 2022, 00:10 Hirnfurz :oops: Hatte bisher nur die WS2812 und die haben nur RGB und mal nach den SK6812 gegoogelt, und da halt RGBW Suchergebnisse gefunden. Beim verlinkten Angebot übersehen, dass die nur RGB sind.
Es gibt die SK6812 in 3 Versionen.
Die RGB und WWA brauchen 3 Byte pro LED und die RGBW brauchen 4 Byte pro LED.

Zu dem gibt es Versionen wo RGBW Controller verbaut sind die aber nur RGB LED-Dies bestückt haben. Das ist meistens diese ultrabillig Bänder.

Zu dem gibt es die noch in einer WWA Version.
Also amber, warm sunlight and blue white.

Ich beziehe meine LEDs hier her:
https://www.opscoled.com/en/

Grüße Jan
frickelfred56
Beiträge: 230
Registriert: Mo 16. Feb 2015, 13:50

Re: Der AVR-/ARDUINO-Faden

Beitrag von frickelfred56 »

Moin
Ich brauch mal eureb rat oder Hilfe.
ich versuche unter der Arduinoumgebug auf einen Raspi4 einen Attiny85 zu programieren.
Ich habe dazu einen Nano als ISP geflasht. und den Attiny85 nach diesem Link
https://create.arduino.cc/projecthub/ar ... uno-afb829
angeschlossen.

das klappt nicht, und es kommt immer die Meldung

Code: Alles auswählen

Arduino: 1.8.19 (Linux), Board: "ATtiny25/45/85, ATtiny85, Internal 1 MHz"

Der Sketch verwendet 2458 Bytes (30%) des Programmspeicherplatzes. Das Maximum sind 8192 Bytes.
Globale Variablen verwenden 178 Bytes (34%) des dynamischen Speichers, 334 Bytes für lokale Variablen verbleiben. Das Maximum sind 512 Bytes.
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x15
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x15

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x14

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x01
avrdude: stk500_initialize(): (a) protocol error, expect=0x14, resp=0x10
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

avrdude: stk500_disable(): unknown response=0x12
Der ausgewählte serielle Port avrdude: stk500_disable(): unknown response=0x12
 ist nicht vorhanden oder das Board ist nicht angeschlossen


Dieser Bericht wäre detaillierter, wenn die Option
"Ausführliche Ausgabe während der Kompilierung"
in Datei -> Voreinstellungen aktiviert wäre.

leider finde ich im Netz keine brauchbaren hinweise bis auf
das hier https://github.com/arduino/Arduino/issues/5520
die da angesprochene Änderung ist aber mittlerweile so eingepflgt.
Gibt es da noch weitere hinweise oder Lösungen für mein Problem?

Frickelfred
bastelheini
Beiträge: 1663
Registriert: So 11. Aug 2013, 13:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von bastelheini »

Brauche ebenfalls Hilfe:

hab mir einige attiny85 digispark clones besorgt. Im Forum steht ja das der Original Bootloader nicht so pralle ist. Daher soll ein anderer drauf. Folgender klingt gut: https://www.mikrocontroller.net/article ... _Dannegger
Ich arbeite unter Windows, mit make und dergleichen hab ich bis jetz nix am Hut gehabt. Anleitung befolgt mit dem aktuellen Atmel (Microchip) Studio. Geht nicht so recht.

Daher https://www.mikrocontroller.net/article ... Toolchain) befolgt, auch die Beispiele runtergeladen (https://www.mikrocontroller.net/topic/1 ... le#3718967).

Die Voraussetzungen habe ich erfüllt. Zusätzlich noch das obendrüber erwähnt avr-gcc installiert. Bei der cygwin Installation das Paket make gewählt und installiert.

Wenn ich jetzt in der Windows Eingabeaufforderung zu dem Ordner navigiere bekomme ich:

Code: Alles auswählen

C:\temp\fastboot-2.9>make clean
Makefile:125: atmel_def.mak: No such file or directory
./_conv.awk atmel/m32def.inc | gawk '/PAGESIZE|SIGNATURE_|SRAM_|FLASHEND|BOOT/' > atmel_def.h
Der Befehl "." ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
Makefile:171: recipe for target 'atmel_def.h' failed
make: *** [atmel_def.h] Error 255
In den Threads zum oben genannten Wiki Artikel steht, dass die fehlende "atmel_def.mak" wohl normal ist und ignoriert werden kann, da sie wohl erst erzeugt wird. Mit dem darauffolgenden Fehler kann ich aber nichts anfangen. Wer kann mir da über die Straße helfen? Ich weiß auch nicht so recht welches make nun genommen wird. Hat Windows 10 mittlerweile was eingebautes, oder nimmt es das cygwin Dings? Oder das aus avr-gcc? Bei der gezielten Auswahl kommt

Code: Alles auswählen

C:\>C:\SysGCC\avr\bin\make.exe
make: *** No targets specified and no makefile found.  Stop.

C:\>C:\SysGCC\avr\bin\make.exe C:\temp\fastboot-2.9\makefile-m8
make: Nothing to be done for `C:\temp\fastboot-2.9\makefile-m8'.
Hilft mir auch nicht wirklich weiter :(

Ich wollte den Bootloader halt nehmen da er für verschiedene AVR konfiguriert werden kann, die Pins bequem festgelegt werden können und auch via onewire Zugriff möglich ist.
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

meine Meinung:
ob der Bootloader taugt oder nicht, kann ich nicht beurteilen...
ist das Hauptproblem der Soft USB (Mist).
Ich jedenfalls werde keinen Bootloader mehr benutzen beim Tiny.
jodurino
Beiträge: 2088
Registriert: So 17. Nov 2013, 20:43

Re: Der AVR-/ARDUINO-Faden

Beitrag von jodurino »

IPv6 hat geschrieben: Fr 5. Aug 2022, 23:49 Wie kommst du darauf, dass das RGBW LEDs sind?
Sowohl die Artikelbeschreibung als auch das Datenblatt von diesen 5 mm LEDs spricht nur von RGB.

Die Neopixel sind recht empfindlich was die Spannungsversorgung angeht, die typischen LED-Streifen oder kleinen Platinchen haben immer einen 100 nF Kondensator direkt an der LED über die Spannungsversorgung. Pack doch auch mal an deine LEDs je einen 100 nF Kondensator, vielleicht ändert das was?
JA genau das war es denke ich, die erste Verdrahtung ist ja über jeden Zweifel erhaben (hope) nur das die Kondensatoren fehlten.

Jetzt habe ich die 5V extra versorgt und nicht mehr vom ArduinoPin genommen
jede LED hat einen 100nf Kondensator und ein 1000µF Elko ist noch mal parallel zu den LEDs
die Datenleitung ist kurz und ich habe ein 470 Ohm Widerstand an D_In der ersten LED

EDIT sagt: guck mal Foto:
Bild
Falls sich einer doch noch wundern sollte, daß rot/weiße Kabel ist 0,75 und bedeutet hier im Gerät +5V. Denn rot ist eigentlich für +12V in diesem Gerät gedacht, aber die 0,75er Leitung ist zu unhandlich am LEDPin


Logisch sind sie G_R_B und nicht R_G_B was ich erst immer noch im Kopf haben muss, aber das kann man ja beachten.

Vielen Dank für die Tipps

jodurino
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

Kann mir mal jemand den Watchdog erklären?
Was macht der und was macht er nicht?
Anscheinend bleibt der Speicherinhalt erhalten trotz das Setup() ausgeführt wird.
ich hab diese Meldung im EEprom gespeichert:
s_6868_4921_0
s=Setup_millis()/100_ Motordrehzahl_ mcusr Register
die wird in Setup() erzeugt.
:?:
oder kann das sein das der Reboot gar nicht vom Watchdog ausgelöst wird sondern von einem Hardware Problem?
Diese sporadischen reboots fallen zusammen mit der Auslösung eines Relais das einen Motor steuert, zwar mit Freilaufdiode aber wer weis?
ich verstehs nicht.
Benutzeravatar
Finger
Administrator
Beiträge: 7392
Registriert: Di 12. Jun 2012, 20:16
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Finger »

Das sind ein wenig zu wenig Informationen :-) Der Watchdog ist nur ein Timer, der läuft irgendwann über und löst einen Reset aus. Ausser, dieser Timer wird regelmäßig und rechtzeitig zurückgesetzt. Bei den kleinen AVRs kann der auch nicht durch dein Programm angehalten werden. Das ist quasi wie ein kompletter Neustart.

Warum du jetzt in einen Reset läufst ist unklar. Du kannst folgende Dinge tun:

1. Watchdog abschalten und schauen, was passiert
2. Dir das Register für die Resetquelle nach dem Start anschauen. Da steht z.B. drin, ob das Ding in einen Brownout gelaufen ist, der Watchdog ausgelöst hat und so weiter

Die 2. bedingt aber, das der Bootloader nicht da ist, der setzt das Register nämlich zurück. Hast du die Möglichkeit, den wegzuhauen?

Mit
ich hab diese Meldung im EEprom gespeichert:
s_6868_4921_0
s=Setup_millis()/100_ Motordrehzahl_ mcusr Register
die wird in Setup() erzeugt.
kann ich so im Moment nichts anfangen. Kannst du mal sagen, welches Zielsystem du nutzt und vielleicht den ganzen Code posten?
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

das läuft auf einem Nano 328p 16 mhz, komplett wird zu viel glaub ich, hier das relevanteste:

Code: Alles auswählen

/*Saving the value of MCUSR in \c mcusr_mirror is only needed if the
 application later wants to examine the reset source, but in particular,
 clearing the watchdog reset flag before disabling the
 watchdog is required, according to the datasheet.*/
uint8_t mcusr_mirror __attribute__ ((section (".noinit")));

void get_mcusr(void) __attribute__((naked))
__attribute__((section(".init3")));
void get_mcusr(void) {
	mcusr_mirror = MCUSR;
	MCUSR = 0;
	wdt_disable();
}

volatile uint16_t rPM = 0;
setup(){
init zeugs....
rec.addMsg(rec.MSG_AVR_START, millis(), rPM, mcusr_mirror, true);
// wie kann millis hier 686800 liefern?
mcusr_mirror = 0x00;
wdt_enable(WDTO_250MS);
}
loop(){
  	........
	wdt_reset();
}
die Methode addMSG legt die Meldung in ein Array, die werden dann wenn Zeit ist in den EEprom geschrieben.
Bootloader ist noch drin, technisch kann ich ihm rausschmeißen, flashen wird dann umständlich weil das sehr verbaut ist.
Muss ich wohl machen um einen zuverlässigen Register Inhalt zu kriegen.

hier ein Ausschnitt aus dem logging:

Code: Alles auswählen

P_6395_10781_33
B_6447_7031_155 //reguläre logging einträge....
B_6484_5156_106
Q_6744_10078_255
P_6744_10078_46
B_6867_4921_100
s_6868_4921_0 // hier neustart
Q_7095_10312_255
P_7095_10546_47
B_7149_8203_186
Q_7437_10546_255
P_7438_10546_54
Q_7465_10781_255
P_7465_10781_39
B_7511_7968_179
B_7560_5625_118
s_7563_5625_0// hier neustart
Q_7814_10312_255
die erste Zahl ist die Laufzeit in 1/10sec,
die zweite die Motordrehzahl,
die dürfte ja noch nicht bekannt sein wenn das Ding neu initialisiert, und die Laufzeit kleiner.
Der flüchtige Speicher scheint aber komplett unangetastet zu sein.
Warum, ist die/meine Hauptfrage.
Die Ursache für den Reset, kann keiner wissen, muss ich dann erforschen.

Testen kann ich nur im Betrieb.
ich kann mir's nicht leisten das sich der aufhängt.
hatte ich vermutlich schon, daher der Watchdog.
Benutzeravatar
Finger
Administrator
Beiträge: 7392
Registriert: Di 12. Jun 2012, 20:16
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Finger »

OK, ich wusste garnicht, das

wdt_disable();

unsterstützt wird. Ist mir prinzipiell unsympatisch, aber manchmal geht das nicht anders. Was passiert, wenn du den Watchdog dauerhaft ausschaltest? Was mir gerade noch einfällt: Einstreuungen über das USB-Kabel. Ich hab für sowas schon optische Insolatoren gebaut um das in den Griff zu kriegen. Oder Kabel ab und nur den TX-Pin vom Controller über einen Optokoppler in den PC geschleust um Debugausgaben zu sehen.
Was bedeuten Buchstaben und die dritte Zahl? Ich behaupte, du hast garkeinen Reset....
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

hab den code nur aus der wdt.h rauskopiert, keine Ahnung ob das das tut.
hab das disable übernommen aus Angst, nicht das der in eine Todesschleife gerät.

die Grossbuchstaben sind reguläre Ereignisse, die letzte Zahl ist meist eine Zeitdauer (ms)
oder eben der MCUSR Inhalt (der gelogene)

Ein USB Kabel hängt tatsächlich dauerhaft dran, verdammt.
Finger hat geschrieben: Mo 5. Sep 2022, 11:32 Ich behaupte, du hast garkeinen Reset....
ist das gut oder schlecht? :lol:
hab auch schon den Verdacht gehabt und gesucht, finde aber keine Erklärung für die am Schuss stehende Null.
Das will nichts heißen, ich kenne mich für total bescheuerte Programmier- oder auch Löt-Fehler.
Wenn es nicht sein kann! das der Speicher beim Reset erhalten bleibt, muss es irgendsowas sein.
Hilft mir auch weiter. Danke :!:

Was passiert wenn ich den Watchdog jetzt wegnehme kann ich nicht sagen.
Kann's nur selten, auf abgesperrter Strecke, testen. Dieses Jahr eh nicht mehr.
Außerdem passiert das ja nur sporadisch.
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Moin, ich löte mal wieder in C herum:

Ich hab einen Status INT zb:
Status= 0b11000001
Das ist ein Statusregister und ich möchte jetzt das Statusregister als einzelne Strings senden, also Zb bei
0b11000001

Code: Alles auswählen

7 CHG : 6 DSG : 5 VGOOD: 4 OVTEMP : 3 UV : 2 OV : 1 OCD : 0 SCD
soll heraus kommen

CHG, DSG, SCD

Wie löse ich das ohne 8 If schleifen?
so:?

char reg[7][6]{"CHG","DSG","VGOOD","OVTEMP","UV","OV","OCD","SCD"}

for ( int a = 0; a<255;a**){
int count=(status|a);
outstring= reg[count];
print (outstring);
}
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

So gehts:

Code: Alles auswählen

char reg[8][7]{"SCD","OCD","OV","UV","OVTEMP","VGOOD","DSG","CHG"};

Code: Alles auswählen

int status = read_reg(0x00);
  for (int a = 0; a <= 7; a++)
  {
    int out = status & (1 << a);
    if (out)
    {
      Serial.println(reg[a]);
    }
  }
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

huch, wenn ich nach nano v3 suche, bekomme ich vermehrt Angebote mit tiny88 oder mega168,
anstatt mega328p.
?
die mit tiny88 scheinen keinen usb chip zu haben. soft usb? nee danke.
die mit mega168 haben einen ch340.

was für ein bootloader werden die wohl haben, bzw wie compilier ich und krieg den code da drauf?
hat jemand schon Erfahrungen mit denen?
Benutzeravatar
Alexander470815
Beiträge: 2371
Registriert: So 11. Aug 2013, 15:42
Wohnort: D:\Hessen\Gießen

Re: Der AVR-/ARDUINO-Faden

Beitrag von Alexander470815 »

Im Zweifelsfall einfach mit einem USBasp.
Die Nano mit den 328p drauf haben jetzt teilweise auch 328pb drauf.
Neulich habe ich aber welche erwischt die fehlerhaft sind und manchmal abstürzen.
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

das problem scheint verbreitet: https://www.mikrocontroller.net/topic/449723
https://www.pololu.com/file/0J1464/Atme ... T15007.pdf

vielleicht wär das mit dem tiny88 gar nicht doof. kost die Hälfte.
Toolchain (attinycore, ohne bootloader) hab ich, Adapter auch.
Hab aber erstmal bei Ali mit, hoffentlich, 328p bestellt.
Benutzeravatar
Alexander470815
Beiträge: 2371
Registriert: So 11. Aug 2013, 15:42
Wohnort: D:\Hessen\Gießen

Re: Der AVR-/ARDUINO-Faden

Beitrag von Alexander470815 »

Auf denen die ich habe steht 328P drauf, sie identifiziert sich aber als 328PB.
6stk von dem einen Verkäufer laufen auch klaglos mit 16MHz und verrichten ihre Arbeit, die anderen 9stk aus anderer Quelle stürzen alle paar Sekunden ab. Der Programmcode zählt einfach nur variablen hoch und gibt diese auf der UART aus.
Von daher gehe ich von einem Hardware defekt aus.
Antworten