Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

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

Benutzeravatar
Daniel
Beiträge: 859
Registriert: Mi 14. Aug 2013, 21:43
Wohnort: NRW

Re: Der AVR-/ARDUINO-Faden

Beitrag von Daniel »

Ja es ollen 2 Motoren mit je 3 V und etwa 200 mA gesteurt werden.

Mehr nicht.

Da werde ich ein Shield kaufen.

danke
Zuletzt geändert von Daniel am Do 4. Feb 2021, 02:03, insgesamt 1-mal geändert.
Benutzeravatar
Daniel
Beiträge: 859
Registriert: Mi 14. Aug 2013, 21:43
Wohnort: NRW

Re: Der AVR-/ARDUINO-Faden

Beitrag von Daniel »

Daniel hat geschrieben: Mi 3. Feb 2021, 23:43 Ja es sollen 2 Motoren mit je 3 V und etwa 200 mA gesteuert werden.

Mehr nicht.

Da werde ich ein Shield kaufen.

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

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

Idee: Temperaturen messen am Motor (Krümmer ausgenommen).
zu erwarten sind so 200° etwa.
PT1000 sind da. Auswertung mit Nano.
Gibt's Einwände gegen das hier?
2021-02-04 10_57_18-Window.png
vergessen:
die pt1000 sollen typ. 1mA sehen, maximal 7mA.
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

für 2D geometrie hab ich nix schönes gefunden, ich hab eine Java klasse die ich gern benutze und hab die daher nach c++ umgeschrieben.
ich hoffe es zumindest, kann keine Garantie übernehmen für verbogene Zeiger, performance etc. Kompilieren tuts fehlerfrei.
vielleicht mag jemand da durchschauen.
Sebstverständlich auch gern benutzen.
im archiv sind alle dateien.

Abfallprodukt, Tip of the Day:
ein destruktor 'virtual ~Vect2();' führt zu: "undefined reference to `vtable for...."
so muss der aussehen 'virtual ~Vect2(){};'
Dateianhänge
Vect2c++.zip
(11.35 KiB) 26-mal heruntergeladen
j.o.e
Beiträge: 541
Registriert: Fr 29. Nov 2019, 01:15

Re: Der AVR-/ARDUINO-Faden

Beitrag von j.o.e »

(Ich packs mal hier rein, obwohl der Trigger aus "Ein Erdkeller entsteht", speziell den vorgestellten Datenloggern, kam ...)

Mich wundert immer wieder, wie kreativ man ein Datum darstellen kann. Neuweltliche Schreibweisen wie 09/11/01, die so gut wie alles bedeuten können, lass ich mal außen vor. Dabei gibt es schon seit Jahrzehnten recht ordentliche Vorschläge.

DIN 5008:2020-03 lässt 2 numerische Schreibweisen zu
bevorzugt:
  • 2003-05-17 | YYYY-MM-DD
optional:
  • 17.05.2003 | DD.MM.YYYY (national)
Dann gibt es noch ISO 8601:2004 (EN 28601) mit
Basisformat:
  • 20030517 | YYYYMMDD
Erweitertes Format:
  • 2003-05-17 | YYYY-MM-DD
Anmerkung zur DIN 5008:
Die DIN sah schon in 1996 vor, dass für die numerische Schreibweise nur das Format gemäß ISO 8601 zulässig sei, also YYYY-MM-DD.
In 'Schland waren wir aber offensichtlich zu doof, das durchzuziehen - weshalb sich die DIN dann erbarmen musste.

Witzig wird die Sache, wenn man das 'optionale' DIN5008-Format (also den vorgestrigen Quatsch) in Dateinamen verwendet - und dann nach dem Dateinamen sortieren lässt ...

Jedem, der damit zu tun hat, empfehle ich ernsthaft, in einer ruhigen Minute sich mal https://de.wikipedia.org/wiki/ISO_8601 reinzuziehen.
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Es gibt sog. ITler/Admins die verwenden Leer- und Sonderzeichen in Verzeichnissnamen auf den Servern.
Oder ganz toll Verzeichnisse mit dem Name /ls.
Da spielt das korrekte Verwenden von Datumsangaben im Dateinamen auch keine Rolle mehr.
Gerne gesehen sind unendlich tiefe Verzeichnissbäume.
So wie zb /Allgemein/Verkauf Inland/Produkte/Aktuell/000-009/Intern/Stückliste/432-111/
MSG
Beiträge: 2182
Registriert: Fr 9. Nov 2018, 23:24
Wohnort: Nähe Dieburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von MSG »

Wir sind in der Firma ein internationales Team mit Franzosen tt/mm/jjjj, Amerikanern mm/tt/jjjj, Spaniern und Deutschen tt.Mm.Jjjj

Das ist zum kotzen, wenn du da 08/11/09 irgendwo liest, das kann alles sein....

Darum habe ich vor Jahren schon das ISO Format durchgesetzt jjjj-mm-tt
Benutzeravatar
Arndt
Beiträge: 2589
Registriert: Fr 28. Jun 2013, 13:42
Wohnort: einen Schritt über den Abgrund hinaus

Re: Der AVR-/ARDUINO-Faden

Beitrag von Arndt »

Ach herrlich, Ihr sprecht mir aus der Seele!
Und ich habe einmal mehr das Gefühl hier in unserer Gemeinschaft eine Referenz der Normalität und Vernunft zu haben.
Mein Code ist mit nichten perfekt, oder ordentlich und optimal, aber das Datumsformat ist, wie ich es vor geraumer Zeit einmal gelernt habe.
Von einer DTG (aus der Funkterei) habe ich mittlerweile Abstand genommen, das ist denn für so eine lokale Anwendung doch etwas zuviel des Guten und schwer lesbar. ;)

Aber korrespondiernd zu den Kommentaren stelle ich belustigt fest, dass (bis auf das Verzeichnis '/ls' ) auf unseren Servern, Netzlaufwerken, Dokumentenmanagementdatenbanken in der 4ma echt das komplette Portfolio an Schandtaten zu finden ist :lol:
Toller Trend ist auch die Apfel-strategie, "wir werfen alles auf einen kryptischen Haufen und nur ein Datenbanksystem findet vielleicht wieder, was Du suchst"
Also das /ls-Verzeichnis müsste ich vielleicht der Vollständigkeit halber mal vorschlagen...
'$' am Anfang von Passwörtern sind auch immer wieder eine tolle Idee.

BTT, die verkürzte Schreibweise YYYYMMTT hat noch den Vorteil, dass sie 3 '-' im Dateinamen spart.
Natürlich ist strenggenommen YYMMTT noch kompakter und bei firmenweiter, einheitlicher Anwendung auch ok, aber sobald Dokumente extern ausgetauscht werden ist das auch schon wieder mehr Chaos als Nutzbringend.
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

YYMMTT geht ja mal gar nicht, da ist der nächste Milleniumbug doch direkt in Reichweite.
Nicht das wir 2100 das selbe Chaos bekommen wie 2000.

Dann soll eine neue Datenbank her:
Ja wie lang soll denn das Datenfeld für den Straßennamen sein, 30 Zeichen müssen aber reichen.

WTF?
255 Zeichen! In allen Datenfeldern.
Wann leben wir denn, 1985??
j.o.e
Beiträge: 541
Registriert: Fr 29. Nov 2019, 01:15

Re: Der AVR-/ARDUINO-Faden

Beitrag von j.o.e »

YY-MM-TT (oder auch YYMMTT) - ich würde das keinesfalls machen. Denn dann bist schon wieder bei dem von MSG zitierten 08/11/09.

ISO 8601 (EN 28601) lässt zwar Abkürzungen zu, wie z.B. YYYY-MM oder auch YYYY. Und ich finde die auch sinnvoll.

Natürlich kann sich eine Haus-Norm ausdenken. Aber wieso sollte man das, wenn es doch schon viele Jahre eine Norm dafür gibt (z.B. seit 1988 im Fall von ISO 8601)? Imho wäre das auch nicht besonders klug, wirft man sich doch dadurch selbst Steine in den Weg. Unterstützung für ISO 8501 gibt es zuhauf - für ACME 0815 wir die Luft sicher dünn. Natürlich kann man da immer mit AWK ran - aber wieso sollte man das provozieren?

Mit der gleichen Begründung kann sich eine Firma auch proprietäre Inhouse-Schrauben ausdenken. Statt M3, M4, M5, ... benutzt man dann J1, J2, ... Jn mit n = Bruchteil der Breite des großen Zehennagels vom Chef. Die notwendigen Tools (Gewinde-Bits) bäckt man sich dann halt selbst ...

Wenn es um eine platzsparende Darstellung, und nur darum geht (im Besonderen auch nicht menschlesbar sein muss) - könnte ich mir noch ein time_t, sprich 'Sekunden seit '1970-01-01T00:00Z', vorstellen.

just my 2 ct
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 »

Ist wohl eine Abwägung zwischen menschenlesbar vs maschinenlesbar.

Im Englischen, Französischen und Deutschen wird in der Kommunikation Mensch-Mensch aus Tradition das Format Tag/Monat/Jahr/Uhrzeit verwendet. Und die Tradition hält sich wacker, auch wenn sie keinen Sinn ergibt. Siehe auch Zwanzig-Eins im Kalenderfaden.

Wenn ich bei Dateinamen Jahreszahlen brauche sind das meistens Ordner. Dann steht die Jahreszahl (YYYY) vorne, aber sonst steht da keine weitere Datumsinformation mehr, sondern direkt Inhaltsinfo. Gibt ja auch immernoch Dateiattribute, die das entsprechend feiner auflösen, muss demnach nicht in den Namen rein, mMn.

Die ISO8601 läuft mir persönlich überhaupt nicht rein, ich verwechsel dann immer erstmal Monat und Tag, bis ich drauf komm, das das ja andersrum ist. Meine Logs will ich auch lesen können, deswegen schreib ich das da so, dass ich es auf Anhieb verstehe, für alle Anderen steht dabei, wie das Datum zu lesen ist.

Solange man es schafft, dass das Format eindeutig lesbar ist, ist für mich die Welt in Ordnung.
radixdelta
Beiträge: 2331
Registriert: So 11. Aug 2013, 20:25
Wohnort: Nord-Ost-Westfalen

Re: Der AVR-/ARDUINO-Faden

Beitrag von radixdelta »

Im reinen Mensch-Mensch-Kontext ist die Datumsangabe mit der man aufgewachsen ist vernünftig. Mit der Englischen kann ich z.B. gar nichts anfangen, selbst wenn der Monat abgekürzt oder ausgeschrieben ist weiß ich nie ob dahinter jetzt der Tag oder Jahr gemeint ist. DTG finde ich eigentlich ideal wenn es in der Mensch-Mensch-Kommunikation um inmissverständliche Zeitangaben ankommt. Im Täglichen Leben ist das zu lang und sperrig.

Im Mensch-Maschine-Kontext finde ich eine strenge Ordnung JJJJMMTThhmmss gut, weil das sowohl Maschinen als auch Menschen schnell überblicken und es ist sortierbar.

Im reinen Maschinen-Maschinen-Kontext und wenn man rechnen möchte würde ich mich an den Standard halten den die Tabellenkalkulationen vorgeben. Und da ist 31.12.1899 00:00 als 1 definiert und es wird dezimal mit ganzen Tagen gerechnet.
j.o.e
Beiträge: 541
Registriert: Fr 29. Nov 2019, 01:15

Re: Der AVR-/ARDUINO-Faden

Beitrag von j.o.e »

radixdelta hat geschrieben: Mi 17. Feb 2021, 13:16 Im reinen Maschinen-Maschinen-Kontext und wenn man rechnen möchte würde ich mich an den Standard halten den die Tabellenkalkulationen vorgeben. Und da ist 31.12.1899 00:00 als 1 definiert und es wird dezimal mit ganzen Tagen gerechnet.
Kann man machen - und z.B. auf https://access-im-unternehmen.de/Mit_Da ... _arbeiten/ referenzieren:
"Der Beginn der Zeitrechnung ist für Access der 30. Dezember 1899. Dieser Tag entspricht dem Datumswert 0."

Wenn da nur nicht https://docs.microsoft.com/de-de/office ... ate-system wäre:
"Microsoft Excel unterstützt zwei verschiedene Datumssysteme. Diese Systeme sind das 1900-Datumssystem und das 1904-Datumssystem.
Im 1900-Datumssystem wird der erste unterstützte Tag der 1. Januar 1900. Wenn Sie ein Datum eingeben, wird das Datum in eine fortlaufende Zahl umgewandelt, die die Anzahl der vergangenen Tage darstellt, beginnend mit 1 für den 1. Januar 1900."


Also Sachen gibts!
radixdelta
Beiträge: 2331
Registriert: So 11. Aug 2013, 20:25
Wohnort: Nord-Ost-Westfalen

Re: Der AVR-/ARDUINO-Faden

Beitrag von radixdelta »

Nunja, Excel halt... Ich habe vor einiger Zeit mit erschrecken feststellen müssen wie unbenutzbar das mittlerweile ist. :roll:
Da ist sich Winzigweich also nicht so recht einig. Irgendwie... typisch.

Grundsätzlich ist es ja egal wo man den Nullpunkt setzt, das lässt sich ja einfach umrechnen.

Ich meine nur in Bezug auf:
j.o.e hat geschrieben: Di 16. Feb 2021, 12:38 könnte ich mir noch ein time_t, sprich 'Sekunden seit '1970-01-01T00:00Z', vorstellen.
Würde ich empfehlen in Tagen zu rechnen, nicht in Sekunden. Dann bleiben die Rechenoperationen gleich und man muss nicht nochmal umdenken und auch nicht nochmal umrechnen, abgesehen von evtl. nötiger Addition. Dann kommen auch die in die Tabellenkalkulation eingebauten Formeln und Operationen damit klar, selbst wenn das Datum um x Tage verschoben ist.
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 »

radixdelta hat geschrieben: Mi 17. Feb 2021, 13:16 Im Mensch-Maschine-Kontext finde ich eine strenge Ordnung JJJJMMTThhmmss gut, weil das sowohl Maschinen als auch Menschen schnell überblicken und es ist sortierbar.
Wenn da jetzt noch _ zwischen die Tokens kommen, dann kann mans auch wirklich lesen.
Bei Android sind die Bilder ja so numeriert, da krichste Augenkrebs :lol:
Benutzeravatar
Bastelbruder
Beiträge: 11482
Registriert: Mi 14. Aug 2013, 18:28

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bastelbruder »

[fast-OT]Bei IrfanView ist die Standardeinstellung für Screenshot-Dateien ..ddmmyyyy.. (capture_$U(%d%m%Y_%H%M%S)), eine der wenigen Einstellungen die ich immer sofort nach der Installation ändere.[/fast-OT]
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

was mich beim datum am meisten verwirrt ist das morgen heute gestern ist.
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 »

Tag zusammen,

Ich versuche gerade ein VFD-Display an einem Arduino Mega 2560 zu betreiben, scheitere aber an den Begrenzungen der zugehörigen Library.
Das VFD ist ein Noritake Itron CU20025-UW1J und die Library, die ich verwende findet sich hier: https://www.noritake-elec.com/support/d ... tart-guide
(Code Library für CU-U Modelle).

Verwendet wird das parallele M68-Interface (RS, R/W, E, DB0...DB7) und am Mega möchte ich dafür die Pins 32 bis 42 verwenden. Doch mit der Library vom Hersteller geht das einfach nicht.
Wenn ich die Verdrahtung verwende, die dem beiliegenden "HelloDemo.ino"-Beispiel entspricht (Pins 0-11 am Arduino), funktioniert es.

Daher gehe ich davon aus, dass der Ersteller der Library nicht die zusätzlichen Anschlüsse eines Mega 2560 berücksichtigt hat und diese daher nicht gehen. Kann mir jemand zeigen, an welcher Stelle in der Library man schrauben müsste, um die höheren Pin-Nummern zu ergänzen?

Edit: Warum ich nicht die Pins aus dem Beispielcode nehmen möchte? Ich brauche genau diese Pins als PWM-Ausgänge...

Hier noch der Minimal-Code zu testen:

Code: Alles auswählen

#include <CUU_Interface.h>
#include <CUU_Parallel_M68.h>
#include <Noritake_VFD_CUU.h>
#include <util/delay.h>

CUU_Parallel_M68 interface(9,10,11, 0,1,2,3,4,5,6,7);//RS,WR,RD,D0-D7 ==> Funktioniert
//CUU_Parallel_M68 interface(32,33,34,35,36,37,38,39,40,41,42);//RS,WR,RD,D0-D7 ==> Tote Hose

Noritake_VFD_CUU vfd;

void setup() {
  _delay_ms(500);      // wait for device to power up
  vfd.begin(20, 2);    // 20x2 character module
  vfd.interface(interface); // select which interface to use
  vfd.CUU_init();      // initialize module
  vfd.print("Noritake"); // print Noritake on the first line
}

void loop() {
}
he25rb
Beiträge: 35
Registriert: So 4. Dez 2016, 14:18

Re: Der AVR-/ARDUINO-Faden

Beitrag von he25rb »

Versuch mal die :4 in CUU_Parallel_M68.h durch :8 zu ersetzen.

unsigned RS_PIN:4; zu unsigned RS_PIN:8;
...........
unsigned D7_PIN:4; zu unsigned D7_PIN:8;

dann müssten die Ports über 15 funktionieren.

mfg herb
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 »

Das war's!

Heißen Dank!!!

Das Ergebnis wird demnächst bei den fertiggestellten Projekten vorgestellt...
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

das hier ist die ISR von picouart:

Code: Alles auswählen

// PCINT latency is 6 cycles minimum + 2 for rjmp 
// nerdralph.blogspot.com/2020/04/measuring-avr-interrupt-latency.html  
ISR(PCINT0_vect, ISR_NAKED)
//void ISRR(void)
{
    register char c asm ("r16");
    asm volatile (
    "push %[c]\n"
    "in %[c], __SREG__\n"               // save SREG
    "push %[c]\n"
    "cbi %[pcint], %[rx_bit]\n"         // turn off PCINT
    "push r24\n"                        // delay_cycles will use r25:r24
    "push r25\n"
    "ldi %[c], 0x80\n"                  // bit shift counter
    : [c] "=d" (c)
    : [pcint] "I" (_SFR_IO_ADDR(PCMSK)),
      [rx_bit] "I" (PURXBIT)
    );
    // ISR is 18 cycles slower than purx
    if (PURXSTART >= 18 )
        __builtin_avr_delay_cycles(PURXSTART - 18);
    asm volatile (".Lrxbit:");
    __builtin_avr_delay_cycles(PURXWAIT);
    // 5 cycle loop
    asm volatile (
    "lsr %[c]\n"
    "sbic %[rx_pin], %[rx_bit]\n"
    "ori %[c], 0x80\n"
    "brcc .Lrxbit\n"
    "sts purx_data, %[c]\n"             // save received byte
    "pop r25\n"
    "pop r24\n"
    "pop %[c]\n"
    "out __SREG__, %[c]\n"              // restore SREG
    "pop %[c]\n"
    "reti\n"
    : [c] "+d" (c)
    : [rx_pin] "I" (_SFR_IO_ADDR(PURXPIN)),
      [rx_bit] "I" (PURXBIT)
    );
}
wenn ich zusätzlich eine PCintCange lib verwenden möchte(auch pcint0, attiny85),
gibts error gemecker.
man sieht's am kommentar, ich hab schon versucht die umzubenennen und in attachinterupt als routine an die PcIntChange lib zu übergeben.
ich krieg's nicht hin.
geht das irgendwie minimal invasiv, also ohne die libs zu sehr neu zu schreiben.

edit. habs hinbekommen das es baut, allerdings funktioniert die Kommunikation nicht mehr (gut).
kann sein das liegt an meiner Blödheit, oder es geht prinzipiell nicht.
jodurino
Beiträge: 2088
Registriert: So 17. Nov 2013, 20:43

Re: Der AVR-/ARDUINO-Faden

Beitrag von jodurino »

Hallo
da habe ich auch mal wieder ein Problemchen.

Muss eine Rechteckspannung auswerten von 1Hz bis maximal 10kHz, dacht mir mache das wie hier beschrieben:
http://interface.khm.de/index.php/lab/i ... index.html

also an PIN 5, kann ich da nicht auch einen Optokoppler für nehmen anstelle der Schaltung mit dem BC 547?

cu
jodurino
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Sicherlich geht das auch mit einem Optokoppler, solange er schnell genug ist.
Bei maximal 10 kHz sind da aber keine Probleme zu erwarten.
Der Optokoppler kommt halt mit einer Verstärkung < 1 daher, belastet also deine Signalquelle mehr als eine Verstärkerschaltung mit Transistor. Damit der Optokoppler funktioniert muss halt nennenswert Strom durch, das gibt nicht jede Signalquelle her.
Vor einiger Zeit hatte ich da auch mal was mit einem 4N35 gebastelt, weiß aber schon gar nicht mehr was und zu welchem Zweck...
j.o.e
Beiträge: 541
Registriert: Fr 29. Nov 2019, 01:15

Re: Der AVR-/ARDUINO-Faden

Beitrag von j.o.e »

jodurino hat geschrieben: Di 16. Mär 2021, 13:11 Hallo
da habe ich auch mal wieder ein Problemchen.

Muss eine Rechteckspannung auswerten von 1Hz bis maximal 10kHz, dacht mir mache das wie hier beschrieben:
http://interface.khm.de/index.php/lab/i ... index.html

also an PIN 5, kann ich da nicht auch einen Optokoppler für nehmen anstelle der Schaltung mit dem BC 547?

cu
jodurino
Braucht du die galvanische Trennung - oder wieso Optokoppler?
Beschreib mal dein Signal / deine Signalquelle etwas genauer. Liefert die Quelle genug Power, um die LED im Optokoppler direkt anzusteuern?

Die Schaltung mit dem BC547 ist suboptimal, wenn nicht gar ungeeignet dimensiniert.

Dem Arduino-Pin was vorzuschalten ist vom Prinzip her keine schlechte Idee, z.B. wenn man über ein längeres Kabel da ran gehen will, das womöglich sogar noch an-und abgesteckt wird.
jodurino
Beiträge: 2088
Registriert: So 17. Nov 2013, 20:43

Re: Der AVR-/ARDUINO-Faden

Beitrag von jodurino »

j.o.e hat geschrieben: Di 16. Mär 2021, 16:29
jodurino hat geschrieben: Di 16. Mär 2021, 13:11 Hallo
da habe ich auch mal wieder ein Problemchen.

Muss eine Rechteckspannung auswerten von 1Hz bis maximal 10kHz, dacht mir mache das wie hier beschrieben:
http://interface.khm.de/index.php/lab/i ... index.html

also an PIN 5, kann ich da nicht auch einen Optokoppler für nehmen anstelle der Schaltung mit dem BC 547?

cu
jodurino
Braucht du die galvanische Trennung - oder wieso Optokoppler?
Beschreib mal dein Signal / deine Signalquelle etwas genauer. Liefert die Quelle genug Power, um die LED im Optokoppler direkt anzusteuern?

Die Schaltung mit dem BC547 ist suboptimal, wenn nicht gar ungeeignet dimensiniert.

Dem Arduino-Pin was vorzuschalten ist vom Prinzip her keine schlechte Idee, z.B. wenn man über ein längeres Kabel da ran gehen will, das womöglich sogar noch an-und abgesteckt wird.
Hallo
ja aus dem Inverter kommt ein Optokoppler fähiges Signal.
Anse
Beiträge: 2278
Registriert: Mo 12. Aug 2013, 21:30
Wohnort: Bühl (Baden)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Anse »

Schneller Optokoppler klingt nach einem Job für 6N137. Bis 10 MHz und gleich mit schönem logik Level Ausgang.
j.o.e
Beiträge: 541
Registriert: Fr 29. Nov 2019, 01:15

Re: Der AVR-/ARDUINO-Faden

Beitrag von j.o.e »

jodurino hat geschrieben: Di 16. Mär 2021, 20:14 ja aus dem Inverter kommt ein Optokoppler fähiges Signal.
Ich seh jetzt nichts was gegen einen Optokoppler sprechen sollte. Mach halt einen rein, wenn dir die galvanische Trennung wichtig ist.
jodurino
Beiträge: 2088
Registriert: So 17. Nov 2013, 20:43

Re: Der AVR-/ARDUINO-Faden

Beitrag von jodurino »

Anse hat geschrieben: Di 16. Mär 2021, 20:32 Schneller Optokoppler klingt nach einem Job für 6N137. Bis 10 MHz und gleich mit schönem logik Level Ausgang.
Nun mehr als 10kHz erwarte ich da nicht
j.o.e hat geschrieben: Di 16. Mär 2021, 20:38
jodurino hat geschrieben: Di 16. Mär 2021, 20:14 ja aus dem Inverter kommt ein Optokoppler fähiges Signal.
Ich seh jetzt nichts was gegen einen Optokoppler sprechen sollte. Mach halt einen rein, wenn dir die galvanische Trennung wichtig ist.
Ja ist ja im Auto
Benutzeravatar
sukram
Beiträge: 3063
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

@Fritzler: ich bastel gerade mit deiner bme280 lib auf einem mega8 herum (war grad da). Ist das normal, dass die Lib mit avr-gcc und -Os knapp 5 kb fett wird? Genaue Versionen von gcc und libc kann ich mirgen nachreichen, der PC is nur grad schon aus.

Ich hatte vor, deine Lib, ein 1wire DS1820 Code (900 Byte) von peda (Trollnest Forum) und yaMBSiavr (2kb) zu verheiraten.

Momentan kann ich entweder 1wire + BME + einfache Textausgabe auf Uart oder 1 wire und Modbus zusammenpacken. Für alle 3 reicht der Platz nicht aus...

Kann man da nich irgendwo abspecken? Gut, nächste Woche habe ich dann ein paar Ardu Mini pro (Mega328) hier, da wärs egal. Aber mich treibt es ein wenig um, dass das nicht da rein passen soll :x
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 »

sukram hat geschrieben: Mi 17. Mär 2021, 22:51 Ist das normal, dass die Lib mit avr-gcc und -Os knapp 5 kb fett wird? Genaue Versionen von gcc und libc kann ich mirgen nachreichen, der PC is nur grad schon aus.
Die printfs haste schon verbannt?
Ansonsten sind die 32Bit Miltiplikation sowie Division recht groß.
Das kann der AVR ja nicht in Hardware, aber wird fürs verrechnen der Kalibrierdaten benötigt.
Guck doch mal in die BME280_compensate_X_int32 Funktionen :lol:
Benutzeravatar
sukram
Beiträge: 3063
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

Das werd ich mir heut nachmittag noch mal anschauen, aber ich dachte, die printf sind schon auskommentiert. Wenn ich das richtig gelesen habe, hatte man bei Bosch in den Codebeispielen schon darauf geachtet, dass Divisionen primär durch Shift-Befehle erschlagen werden können. Wobei ich denke, dass Shifts größer 8 Bit eigentlich durch Registertausch vereinfacht werden könnten. Aber das sollte gcc selbst auf die Reihe bekommen.
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 »

Das beschleunigt die Ausführungszeit wenn nicht jedesmal die Lib aufgerufen werden muss.
Sobald aber noch ein 32 Bit Mul/Div über bleibt wird die gcc Lib hinzugelinkt.

Code: Alles auswählen

int32_t var1, var2;
uint32_t p;
        if (p < 0x80000000L){
		p = (p << 1) / ((uint32_t)var1);
	}else{
		p = (p / (uint32_t)var1) * 2;
	}
	var1 = (((int32_t)dig_P9) * ((int32_t)(((p>>3) * (p>>3))>>13)))>>12;
genatzt!

Ja, das ist eher kryptisch, kommt aber so aus dem DB.
Benutzeravatar
sukram
Beiträge: 3063
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

Jau, das meinte ich. Da sehe ich mich schon mit Kästchenpapier und Bleistift die Rechenbewegungen rausschreiben und in Inline-ASM abwickeln... :?
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 »

Das kann man durchaus machen wenn man viel Zeit hat und drauf steht, ja :lol:
Oder eben den Mega16/32/328 nutzen.
Oder auf ARM Umsteigen da gibts Hardware MulDiv in 32Bit.

MulDiv auf Fußpilzebene hatte ich ja schonmal durch, aber in Hardware:
https://fritzler-avr.de/spaceage2/!File ... MulDiv.pdf
MSG
Beiträge: 2182
Registriert: Fr 9. Nov 2018, 23:24
Wohnort: Nähe Dieburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von MSG »

Fritzler hat geschrieben: Do 18. Mär 2021, 15:14MulDiv auf Fußpilzebene hatte ich ja schonmal durch, aber in Hardware:
https://fritzler-avr.de/spaceage2/!File ... MulDiv.pdf
Ist das Teil deiner Doktor/Diplomarbeit? Schon krass, was das für ein Aufwand für Multiplikation/Division ist :o
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 »

MSG hat geschrieben: Do 18. Mär 2021, 19:45 Ist das Teil deiner Doktor/Diplomarbeit? Schon krass, was das für ein Aufwand für Multiplikation/Division ist :o
Ne, das is nur Hobby.
Den Text hab ich an ein paar Abenden runtergerasselt, das is doch keine Arbeit.
Aber ich fands erschreckend wie sehr die Fachliteratur so einige Sonderfälle weggelassen hat.
Diese habe ich dann mit diesem 4 Bit Rumschubs C Programm rausgefunden.
Daher musste ich das quasi schreiben auch als Doku für mich zu späterer Zeit.

Zum Aufwand:
Das ist nur ein serieller MulDiv.
Der rechnet nicht paralel, diese wären dann ne Hardwareschlacht bei 32Bit.
MSG
Beiträge: 2182
Registriert: Fr 9. Nov 2018, 23:24
Wohnort: Nähe Dieburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von MSG »

Fritzler hat geschrieben: Do 18. Mär 2021, 19:49Ne, das is nur Hobby.
Den Text hab ich an ein paar Abenden runtergerasselt, das is doch keine Arbeit.
*staun* du hast meinen größten Respekt :)
Bumbum
Beiträge: 280
Registriert: Mi 22. Apr 2015, 19:04

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bumbum »

Hallo,

ich habe am Balkon einen LED-Streifen mit WS2812. Gesteuert wird das ganze über einen Wemos Mini. Ich nutze das in Verbindung mit einem Türsensor als Balkon-Beleuchtung und je nach Jahreszeit und Feiertag als Dekorationsbeleuchtung. Das Problem ist, dass der Wemos mit seinem WLAN dazwischenfunkt. (Der Gag war einfach zu passend :D )

Die WS2812 wollen ja alle in einem Rutsch mit Daten gefüttert werden. Wenn aber ein WLAN-Interrupt dazwischenkommt funktioniert das nicht und die LEDs zeigen für eine kurze Zeit etwas falsches an. (Meissten natürlich irgendeine grelle Farbe in voller Helligkeit) Die Nachbarn müssen uns schon für bekloppt halten...

Es gibt zwar die Möglichkeit die Interrupts während der Aktualisierung der LEDs abzuschalten. Dann stürzt aber das Betriebssystem des Wemos gelegentlich ab.

Mein erster Lösungsansatz war andere LEDs mit Clock-Leitung. (z.B. APA102). Die Idee habe ich aber verworfen, weil der aktuelle Stripe schön unsichtbar und wetterfest eingebaut ist.

Meine zweite Idee ist einen Controller dazwischenzuschalten. Da ich WLAN benötige, stelle ich den Wemos z.B. auf APA102 LEDs um. Diesen Datenstrom empfange und speichere ich in einem anderen Controller und dieser gibt den Datenstrom dann passend an meine WS2812 aus. Nach kurzer Überlegung bin ich aber zum Schluss gekommen, dass der Controller dafür aber ganz schön schnell sein muss und auch die Programmierung nicht ganz trivial sein wird. Eigentlich bräuchte ich etwas mit Multithreading.

Die dritte Idee ist ein RAM mit zwei Schnittstellen zu suchen (gibt es ja z.B. in alten 8-Bit Computern, wenn die Grafikeinheit den gleichen RAM wie die CPU nutzt). Dann würden zwei kleine Controller genügen, einer der den APA102 Datenstrom vom Wemos empfängt und in den Ram packt und ein anderer, der aus dem RAM die WS2812 füttert. Eine Handshake-Leitung zwischen den Controllern sollte dann passend sein.

Diese Idee habe ich weiter gesponnen, ob das nicht vielleicht auch nur mit den zwei Controllern ohne RAM dazwischen geht. Dann müsste der erste aber den kompletten Datenstrom zwischenspeichern und dann auf Anfrage an den zweiten weitergeben. Dies kann für die Geschwindigkeit parallel geschehen.

Wer hat noch weitere Ideen oder wie ist eure Meinung zu meinen?

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

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

auaua. vielleicht einfacher die Absturz Ursache zu beseitigen.?
muss doch erlaubt sein den interupt auszusetzen.?
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 »

die Ente lieferte bei "ws2812 interrupt free" dieses Ergebnis. Hab mir das noch nicht näher angeschaut, aber könnte was sein?
Bumbum
Beiträge: 280
Registriert: Mi 22. Apr 2015, 19:04

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bumbum »

Hallo,
ch_ris hat geschrieben: Sa 20. Mär 2021, 13:48 auaua. vielleicht einfacher die Absturz Ursache zu beseitigen.?
Wie ich geschrieben habe liegt die Ursache im Betriebssystem des Wemos. Da habe ich keine Möglichkeit etwas zu ändern und es ist scheinbar nicht vorgesehen die Interrupts zu deaktivieren, wenn WLAN aktiv ist. Solltest du ein Beispiel haben, wie das trotzdem geht wäre ich sehr dankbar, das würde mir viel Arbeit ersparen. Ansonsten wäre es nett wenn du deine Ausdrucksweise überdenkst, bevor du mich für dumm erklärst.

@Später Gast: Danke für den Hinweis. In deinem Link wird ein Teensy genutzt. Der läuft meines Wissens nach mit 96 MHz. Das wäre dann wie im Beispiel meines ersten Lösungsansatz. In deinem Link wird auch DMA vorgeschlagen. Dies kann meine Bibliothek leider nicht und müsste dann auch in einem "Thread" laufen, der von den WLAN-IRQs nicht gestört wird oder? Ist der ESP8266 im Wemos dazu fähig?

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

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

:?:
das war nicht meine Absicht. edit. erschrickt mich sogar etwas, das du es so aufgefasst hast, sorry.
ich hab in anderem Zusammenhang auch schon über verteilte uC nachgedacht. mich hats dann aber vor dem Aufwand gegruselt. daher auaua.
Zuletzt geändert von ch_ris am So 21. Mär 2021, 09:10, insgesamt 1-mal geändert.
Benutzeravatar
Harley
Beiträge: 1160
Registriert: So 11. Aug 2013, 21:16
Wohnort: Regensburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Harley »

Zur Ansteuerung der LED's kannst Du auch einen Raspberry Pi PIco nehmen.
Da gibts ein Beispiel, da ist das zeitkritische Protokoll mit den neuen PIO Hardware-Dingsbums-Prozessoren gemacht.
Absolut schnell und sauber. Belastet die beiden Cortex M0 Prozessoren gar nicht.
Geht RatzeFatze. In MicroPython ein paar Zeile Code, kostet 4.-€ ...
https://www.raspberrypi.org/blog/neopix ... with-pico/
Bumbum
Beiträge: 280
Registriert: Mi 22. Apr 2015, 19:04

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bumbum »

Hallo, Harley,

über den Pico habe ich ebenfalls schon nachgedacht. Das wäre ja wieder mein Lösungsvorschlag 1. Ich kenne den bisher nicht, aber soweit ich informiert bin kann der offiziel 2 Threads. Ich habe allerdings noch nie etwas in Phyton progrmamiert. Da ich gleich mit Hardware-IRQs und Multithreading los legen müsste habe ich gehofft diese steile Lernkurve umgehen zu können.

@ch_ris: Kein Problem, dann handelt es sich nur um ein Missverständnis. Schwamm drüber.

Nach meinen Berechnungen hat ein Standard AVR @ 16 MHz nur 6 Taktzyklen, bis er das nächste "Halbbit" wackeln muss bei der geforderten Taktfrequenz von 800 kHz. Da ist nicht mehr viel Zeit übrig, in der die Daten auch noch empfangen werden. Wenn die Daten dann noch zu einem beliebeigen Zeitpunkt ankommen sehe ich eigentlich gar keine Möglichkeit.

Es ist erstaunlich, dass dieses Problem meines Wissens nach im Netz schon seit über 4 Jahren besteht und ich habe zumindest bis jetzt noch keine vernünftige Lösung dafür gefunden.

Viele Grüße
Andreas
Benutzeravatar
Harley
Beiträge: 1160
Registriert: So 11. Aug 2013, 21:16
Wohnort: Regensburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Harley »

Dann wirds Zeit, mit der Python Programmierung anzufangen! :D
Ich hab doch oben die ultimative Lösung verlinkt.
Einfach abtippen und loslegen.
Die Lernkurve beim Pico ist wirklich sehr flach.
Schau mal hier vorbei:
https://www.youtube.com/c/PrintNPlay/videos

Im obigen Beispiel schreibt der Autor:

We’re going to look at how two features of Pico help solve these problems. Firstly, Programmable I/O (PIO) lets us implement the control protocol on a state machine rather than the main processing cores. This means that we don’t have to dedicate any processor time to sending the data out. Secondly, having two cores means we can use one of the processing cores to dither the NeoPixels. This means shift them rapidly between different brightness levels to make pseudo-levels of brightness.

Das ist genau das, was Du brauchst.
Die Datenausgabe läuft hochpräzise in einer State-Machine. Der Core Nr.1 kümmert sich um das Dithering. Core Nr.2 schaufelt in aller Ruhe die Daten hin und her.
Benutzeravatar
phettsack
Beiträge: 1186
Registriert: Mo 12. Aug 2013, 18:17

Re: Der AVR-/ARDUINO-Faden

Beitrag von phettsack »

Wie wird das bei WLED gelöst, damit habe ich schon einige WS2812 mit angebunden und da flickert nichts. Oder ist mir nicht aufgefallen.
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 »

Also wenn ich das in meiner morgendlichen Verpeiltheit grad nicht komplett falsch verstehe, wird der Pico in der IDE bereits nativ unterstützt.

Muss ich wohl auch mal welche ordern :mrgreen:
Bumbum
Beiträge: 280
Registriert: Mi 22. Apr 2015, 19:04

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bumbum »

Hallo,

ich habe auch mal gegoogelt. Der Support in der Arduino-IDE ist scheinbar erst angekündigt. Mal schauen, wie lange es dauert.

Viele Grüße
Andreas
Benutzeravatar
sukram
Beiträge: 3063
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

Fritzler hat geschrieben: Do 18. Mär 2021, 15:14 Das kann man durchaus machen wenn man viel Zeit hat und drauf steht, ja :lol:
Oder eben den Mega16/32/328 nutzen.
Oder auf ARM Umsteigen da gibts Hardware MulDiv in 32Bit.

MulDiv auf Fußpilzebene hatte ich ja schonmal durch, aber in Hardware:
https://fritzler-avr.de/spaceage2/!File ... MulDiv.pdf
Ha! Es geht doch. 6,2 kb Flashauslastung. Ich habe jetzt einfach noch mal den Code "from Scratch" zusammengebaut. Anscheinend war es keine clevere Idee, den Modbuscode aus einem anderen Projekt zu übernehmen, auch wenn dort nette Zusatzfunktionen wie über Register einstellbare Baudrate/Adresse mit drin waren.

Ich habe jetzt eine Statische Adresse, die bekommt aber als nächstes die unteren 4 Bit über eine Port eingelesen (Jumper).

Abgesehen davon, scheint ausserdem der Speicherbedarf proportional zum Alter des avr-gcc uu sein - habe am Samstag extra Eclipse/Avr/avr-gcc neu auf meinem Büro-PC installiert und diese Fassung zusammengebaut, der erste Versuch war mit avr-gcc aus ubuntu 18.04...
Dateianhänge
IMG_20210322_011558_copy_1612x1209.jpg
IMG_20210322_011607_copy_1612x1209.jpg
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 »

Ja, der AVR Pfad des GCC ist eher verwaist.
Im GCC11 droht es ganz rauszufliegen, weil das keiner mehr anfasst, aber große Änderungen anstehen.
Selbst Microchip juckts nicht wirklich, die haben nur 5000€ in den Kopfgeldpool geworfen.
Die wollen einen wohl zum mplab zwingen. (sau gruselige Software)
Meine Empfehlung wäre GCC 4.7 oder 4.9.2, da geht schon _flash statt progmem und es ist noch eher klein.

Man merkt eben, das die AVRs auf dem absteigenden Ast sitzen, auch wenn noch ein paar neue Tinys rauskamen.

Modbus ist ja auch ein sehr einfaches Protokoll, das ist nur Zeitaufwand den man für die Lib investieren muss.
Ich hab mir ja auch ascon eine Modbuslib gezimmert.
Da hab ich aber eher auf vollständigkeit statt platzersparnis geachtet.
Antworten