Wenn man den besten Preis braucht, muss man wohl auf Ali schauen. Ebay ist bei Nanos so bei 2,70€/Stück. Auf Ali hab ich jetzt auch mal erschwingliche Nano every clones erspäht. Das Original ist mir mit 9€ zu teuer, so gefährlich, wie die bei mir leben. 3,50 sind in Ordnung, wenn sie denn tun.
Der AVR-/ARDUINO-Faden
Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese
- Später Gast
- Beiträge: 1705
- Registriert: Di 5. Apr 2016, 22:03
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Re: Der AVR-/ARDUINO-Faden
String ist böse.
das hier nehme ich zur Ausgabe von Zahlen.
Das kostet ~1.1kB Flash.
gibt's da nicht was (halbwegs bequemes) von Ratiopharm?
edit, hab schon itoa() kostet nur 200byte.
Code: Alles auswählen
void printsval(int16_t number) {
char buf[6];
// String(number).toCharArray(buf, 6);
prints(buf);
}
Das kostet ~1.1kB Flash.
gibt's da nicht was (halbwegs bequemes) von Ratiopharm?
edit, hab schon itoa() kostet nur 200byte.
- Wulfcat
- Beiträge: 1867
- Registriert: Mi 14. Aug 2013, 22:43
- Wohnort: Neuss, NRW, Dland,Kontinent Europa, Planet Erde, 3ter Planet Solsystem, Nördliche Spiralarm Milchstr
Re: Der AVR-/ARDUINO-Faden
Hallo MünsterländerMünsterländer hat geschrieben: ↑Mi 27. Jan 2021, 09:42 @Wulfcat
Ich bin auch in der DAU Klasse unterwegs und habe mal mit dem Kinder Tutorial angefangen. Das war für mich eigentlich ganz passend. Bin dann aber irgendwann versumpft und will jetzt zusammen mit meinem Sohn wieder einsteigen...
https://starthardware.org/lektion-1-vorbereitung/
Jetzt bist du der dritte im Bunde
Schnewittchen hatte mich auch schon angesprochen.
Arbeitest du mit nem Nano oder mit nem Uno Board?
Wie schon geschrieben Ich hab so nen Kit mit Nano und werd jetzt erst einmal ganz stumpf die 12 "Experimente" mit Software durchspielen und anhand der Arduino Refferenz die Befehle der Programme nachgehen und dann versuchen ob ich das Kapire was die da gemacht haben.... Dann anfangen daran herum zu ändern.....Zb LED Bink Geschwindigkeit.....Anderer Port.. Usw... ich denke du weist was ich meine.
Ich schau mir nacher auch mal das tutorial an was du da unter Starthardware aufgetan hast....
Nur muss ich das natürlich dann an meinen Nano anpassen da die da mit Uno arbeiten......
Re: Der AVR-/ARDUINO-Faden
Heute mal ein anderes Lcd angelötet, was definitiv schon mit positiver Kontrastspannung gelaufen ist - das Kontrastpoti war noch angelötet. Die gute Nachricht: Der Transistortester läuft. Die schlechte Nachricht: Es ist ein einzeiliges Lcd... Alles noch mal neu verlöten. Das nächste hat hoffentlich zwei Zeilen. Vorher Code und Schaltung bezüglich Lcd angesehen, ist wirklich schlüssig und sauber gemacht. Die seltsamen Messwerte auf den Datenleitungen kommen daher, dass es recht selten aktualisiert wird und somit immer das zuletzt übertragene Nibble an den Datenleitungen in Ruhe anliegt.
MfG. Andreas
MfG. Andreas
- Münsterländer
- Beiträge: 329
- Registriert: Fr 11. Okt 2013, 14:55
- Wohnort: Borken (bei Holland)
Re: Der AVR-/ARDUINO-Faden
Hallo Wulfcat,
für irgendwelche Modellbahnbeleuchtung für meinen Sohn oder Blinklichter und Sirene am Fahrgeschäft für den Kleinen nehme ich den Nano, weil billig und klein genug aber für mich noch gut zu bedienen. Ich habe einen Mini ein mal benuttz. Aber der hatte keinen USB Anschluß und man musste zu programmieren noch ne Schnittstelle anlöten. Das war mir nix.
Für die Basteleien mit meinem Sohn finde ich den Uno ganz gut, weil nicht so filigran und man kann direkt nen Motorshield u.ä. draufstecken.
Viele Grüße,
Thomas
für irgendwelche Modellbahnbeleuchtung für meinen Sohn oder Blinklichter und Sirene am Fahrgeschäft für den Kleinen nehme ich den Nano, weil billig und klein genug aber für mich noch gut zu bedienen. Ich habe einen Mini ein mal benuttz. Aber der hatte keinen USB Anschluß und man musste zu programmieren noch ne Schnittstelle anlöten. Das war mir nix.
Für die Basteleien mit meinem Sohn finde ich den Uno ganz gut, weil nicht so filigran und man kann direkt nen Motorshield u.ä. draufstecken.
Viele Grüße,
Thomas
Re: Der AVR-/ARDUINO-Faden
Es rennt jetzt, hat 2 Zeilen Text am Lcd und endet in "Unkalibriert!" vor dem Abschalten. Nun kann ein Gehäuse drum herum und ein Anschluss zum Messen dran. Der Querstrom für den Kontrast kann noch kleiner werden, da wird noch ein Widerstand einziehen. Das Ding geht also wie gedacht und dokumentiert. Genau das wollte ich wissen.
MfG. Andreas
MfG. Andreas
- Fritzler
- Beiträge: 12603
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
2x16 LCDs hätt ich auf Lager.
Direkt vom Ali mit schönen Farben:
grüne Schrift auf schwarz
orange Schrift auf schwarz
rote Schrift auf schwarz
weiße Schrift auf blau
Wenn Interesse besteht würd ichs vorher mal testen, das liegt hier schon ne Weile rum.
Direkt vom Ali mit schönen Farben:
grüne Schrift auf schwarz
orange Schrift auf schwarz
rote Schrift auf schwarz
weiße Schrift auf blau
Wenn Interesse besteht würd ichs vorher mal testen, das liegt hier schon ne Weile rum.
Re: Der AVR-/ARDUINO-Faden
Danke, aber der historische Lcd-Schrott in Schwarz auf Grau funktioniert hinreichend gut. Damit geht das Ding in Betrieb. Ist ja bloß ein Einzelstück für den persönlichen Bedarf. So kann ich auch das 2x40 mit Beleuchtung wieder ins Regal packen, war ebenso schon mal verdrahtet und offenbar benutzt worden. Ist hier nur viel zu groß. Ich mag Minimallösungen.
MfG. Andreas
MfG. Andreas
- Fritzler
- Beiträge: 12603
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Dein 20:16 Beitrag hatte ich nicht gesehen, da hab ich noch im Lager gekramt
Hatte nur mitbekommen, dass da ein 1x16 dranne ist und du kein 2x16 gefunden hattest.
Aber das hat sich ja revidiert.
Hatte nur mitbekommen, dass da ein 1x16 dranne ist und du kein 2x16 gefunden hattest.
Aber das hat sich ja revidiert.
Re: Der AVR-/ARDUINO-Faden
puh,
ATTINY85, software gebaut mit 8mhz.
dieser code:
sollte ja eine periode von 200uS, eine Frequenz von 5 kHz ergeben.
wenn ich CKSEL auf ‘0001’ setze (Internal PLL), mess ich am pin 3.2kHz
wenn ich CKSEL auf ‘0010’ setze (8.0 MHz RC oscillator), mess ich am pin 1.6kHz
ob CKDIV8 gesetzt ist oder nicht spielt keine Rolle.
uart funktioniert nur mit PLL.
klingelt da was bei euch?
ich bin ja nicht faul, hab das Datenblatt, aber werd nicht schlau draus.
edit: wenn ich mit 16mHz baue, messe ich je nach CKSEL, 2 bzw. 4 kHz
ATTINY85, software gebaut mit 8mhz.
dieser code:
Code: Alles auswählen
speedoPuls=100;
if (micros() - lastSpeedoSwitch >= speedoPuls) {
speedoHigh = !speedoHigh;
lastSpeedoSwitch = micros();
}
digitalWrite(speedoPin, speedoHigh);
wenn ich CKSEL auf ‘0001’ setze (Internal PLL), mess ich am pin 3.2kHz
wenn ich CKSEL auf ‘0010’ setze (8.0 MHz RC oscillator), mess ich am pin 1.6kHz
ob CKDIV8 gesetzt ist oder nicht spielt keine Rolle.
uart funktioniert nur mit PLL.
klingelt da was bei euch?
ich bin ja nicht faul, hab das Datenblatt, aber werd nicht schlau draus.
edit: wenn ich mit 16mHz baue, messe ich je nach CKSEL, 2 bzw. 4 kHz
Zuletzt geändert von ch_ris am Fr 29. Jan 2021, 11:01, insgesamt 1-mal geändert.
Re: Der AVR-/ARDUINO-Faden
Das Ausführen der Abfrage braucht doch auch etwas Zeit.
Re: Der AVR-/ARDUINO-Faden
ach quatsch, hätt ich fast gedacht.
aber mit 1000 statt 100, komm ich auf glaubwürdige 49x hz.
das ist aber blöd, ich will eine frequenz von bis zu 3kHz lesen, und leicht skaliert wieder ausgeben (Tacho-korrektur).
aber mit 1000 statt 100, komm ich auf glaubwürdige 49x hz.
das ist aber blöd, ich will eine frequenz von bis zu 3kHz lesen, und leicht skaliert wieder ausgeben (Tacho-korrektur).
Re: Der AVR-/ARDUINO-Faden
habs mit tone() probiert, geht nicht.
das mag an dem digistump core liegen, keine ahnung, auf jeden Fall hab ich jetzt mal diese geladen:
https://github.com/SpenceKonde/ATTinyCore
guck an, auf einmal kann ich diverse fuses etc setzen: was ich jezt als timer1 clock setzen soll?versuch macht kluch.
das mag an dem digistump core liegen, keine ahnung, auf jeden Fall hab ich jetzt mal diese geladen:
https://github.com/SpenceKonde/ATTinyCore
guck an, auf einmal kann ich diverse fuses etc setzen: was ich jezt als timer1 clock setzen soll?versuch macht kluch.
- Weisskeinen
- Beiträge: 3950
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Ich habe kürzlich eine Vorliebe zu den Sparkfun Pro Micro, bzw. deren China-Clones entwickelt. Da ist ein Atmega32U4 drauf, der USB schon mit drin hat. Mit dem richtigen Programm gibt der sich auch als Tastatur oder Maus aus und ist auch sonst ganz schnuckelig. Gehört halt zu den Vertretern mit eher wenigen Pins...
Re: Der AVR-/ARDUINO-Faden
Hallo
habe mal diese Schaltung abgezeichnet:
EDIT SAGT ICH SOLL FALSCHE ZEICHNUNGEN NICHT SO LASSEN:
Habe ich von hier:
https://www.roboternetz.de/community/th ... it-Arduino
Detail Seite 3 Post #24
https://www.roboternetz.de/community/th ... uino/page3
Kann man aber nur richtig sehen wenn man angemeldet ist, habe es gewissenhaft abgepinnt.
Ist das wirklich so richtig, kann ich mit der Wechselspannung auf Vref? als IN- und Vref hat er ja verbunden
Und wenn ich die beiden Widerstände (470 +150Ohm ) gegen 1390Ohm ersetze, klappt das Ganze dann auch mit einem 12V Trafo?
Bauteile habe ich schon hier, bin aber beim Basteln so ins Grübeln gekommen
cu
jodurino
habe mal diese Schaltung abgezeichnet:
EDIT SAGT ICH SOLL FALSCHE ZEICHNUNGEN NICHT SO LASSEN:
Habe ich von hier:
https://www.roboternetz.de/community/th ... it-Arduino
Detail Seite 3 Post #24
https://www.roboternetz.de/community/th ... uino/page3
Kann man aber nur richtig sehen wenn man angemeldet ist, habe es gewissenhaft abgepinnt.
Ist das wirklich so richtig, kann ich mit der Wechselspannung auf Vref? als IN- und Vref hat er ja verbunden
Und wenn ich die beiden Widerstände (470 +150Ohm ) gegen 1390Ohm ersetze, klappt das Ganze dann auch mit einem 12V Trafo?
Bauteile habe ich schon hier, bin aber beim Basteln so ins Grübeln gekommen
cu
jodurino
Zuletzt geändert von jodurino am Mo 1. Feb 2021, 09:53, insgesamt 1-mal geändert.
Re: Der AVR-/ARDUINO-Faden
Ja, es besteht ja sonst kein Bezug!
Ja, richtig gerechnet!
Und wenn ich die beiden Widerstände (470 +150Ohm ) gegen 1390Ohm ersetze, klappt das Ganze dann auch mit einem 12V Trafo?
Möglicherweise wirst Du aber je nach Anwendung den Offset in der Sw anpassen müssen.
Re: Der AVR-/ARDUINO-Faden
Überprüf mal die Beschaltung des MCP1525.jodurino hat geschrieben: ↑Sa 30. Jan 2021, 13:57 habe mal diese Schaltung abgezeichnet:
Habe ich von hier:
https://www.roboternetz.de/community/th ... it-Arduino
Schreib dir an die Versorgungsleitungen die Spannungswerte ggü. Arduino GND, dann in einer 2. Farbe ggü. MCP3301.
Re: Der AVR-/ARDUINO-Faden
Hi, dazu müsste ich den aufbauen und dann messen, kann ich ert wieder ab Montag machen.
Sollte aber so sein wie der Kollege es da vorgegeben hat.
OK kam mir komisch vor die Beschaltung, werde es dann nächste Woche probieren.unlock hat geschrieben: ↑Sa 30. Jan 2021, 14:45Ja, es besteht ja sonst kein Bezug!Ja, richtig gerechnet!
Und wenn ich die beiden Widerstände (470 +150Ohm ) gegen 1390Ohm ersetze, klappt das Ganze dann auch mit einem 12V Trafo?
Möglicherweise wirst Du aber je nach Anwendung den Offset in der Sw anpassen müssen.
cu
jodurino
Re: Der AVR-/ARDUINO-Faden
Wie ist die Idee zu bewerten, mit 2 Print Trafos ein Netzteil zu bauen, was einmal 24V AC und 10V DC raus tut?
Könnte man auch per Step Wandler erzeugen, aber ich habe die Dinger nun mal hier liegen.
Dachte, der 24V AC bekommt am Ausgang nur ne Feinsicherung verpasst und hinter den 10V Trafo kommt
eine kleine B2U Schaltung mit Lastwiderstand, damit der im Leerlauf nicht so hoch geht.
Bekomme ich dann AC Müll auf die DC Leitung? oder kann man das durch Schirmung, Ferrit usw. verhindern?
Könnte man auch per Step Wandler erzeugen, aber ich habe die Dinger nun mal hier liegen.
Dachte, der 24V AC bekommt am Ausgang nur ne Feinsicherung verpasst und hinter den 10V Trafo kommt
eine kleine B2U Schaltung mit Lastwiderstand, damit der im Leerlauf nicht so hoch geht.
Bekomme ich dann AC Müll auf die DC Leitung? oder kann man das durch Schirmung, Ferrit usw. verhindern?
Re: Der AVR-/ARDUINO-Faden
Re: Der AVR-/ARDUINO-Faden
Der 1u (gezeichnet am Ausgang des MCP1525) liegt parallel zum 1u parallel zum 100n). Im letzteren 100n ist ein Kurzschluss mit verbaut.
Gut plazieren ist hier wichtiger als doppelt im Schaltbild reinmalen.
Ansonsten müsste es so passen.
Gut plazieren ist hier wichtiger als doppelt im Schaltbild reinmalen.
Ansonsten müsste es so passen.
Re: Der AVR-/ARDUINO-Faden
Hallo,
2 dieser Teile, die einen Spielzeugkran steuern sollen, habe ich diese Teile aUS DER bUCHT. https://www.ebay.de/itm/IC-2262-2272-4- ... 2749.l2649
Brauchen die Teile einen Sketch, oder wie kann ich die Dinger in Betrieb nehmen?
Danke und Gruß
2 dieser Teile, die einen Spielzeugkran steuern sollen, habe ich diese Teile aUS DER bUCHT. https://www.ebay.de/itm/IC-2262-2272-4- ... 2749.l2649
Brauchen die Teile einen Sketch, oder wie kann ich die Dinger in Betrieb nehmen?
Danke und Gruß
- Später Gast
- Beiträge: 1705
- Registriert: Di 5. Apr 2016, 22:03
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Was genau soll mit dem Kran denn passieren?
Wenn du mit der Fernbedienung nur paar Motoren an/ausschalten willst, brauchst du noch nichtmal nen Arduino. Wenn über die 4 Taster 2x Vorwärs/Rückwärts gesteuert werden soll,reicht es, die Ausgänge in sonen einfachen Motortreiber reinzuführen, der macht dann da genau das. Der l293d ist ein billiger, allerdings nicht der effizienteste Motortreiber, der verliert etwa 1,5V oder so von Eingang zu Ausgang. dafür kann er recht hohe Spannungen ab.
Von der Fernbedienung gibt es wohl zwei Typen, einmal latching und einmal momentary. Ich würde für Kran-Fernsteuerung momentary bevorzugen.
Edith meinte noch, dass der Treiber auch die auftretenden Ströme abkönnen sollte, also erstmal kucken, was die Motoren so ziehen an Ampere und dann nach passendem Treiberbaustein suchen.
Wenn du mit der Fernbedienung nur paar Motoren an/ausschalten willst, brauchst du noch nichtmal nen Arduino. Wenn über die 4 Taster 2x Vorwärs/Rückwärts gesteuert werden soll,reicht es, die Ausgänge in sonen einfachen Motortreiber reinzuführen, der macht dann da genau das. Der l293d ist ein billiger, allerdings nicht der effizienteste Motortreiber, der verliert etwa 1,5V oder so von Eingang zu Ausgang. dafür kann er recht hohe Spannungen ab.
Von der Fernbedienung gibt es wohl zwei Typen, einmal latching und einmal momentary. Ich würde für Kran-Fernsteuerung momentary bevorzugen.
Edith meinte noch, dass der Treiber auch die auftretenden Ströme abkönnen sollte, also erstmal kucken, was die Motoren so ziehen an Ampere und dann nach passendem Treiberbaustein suchen.
Re: Der AVR-/ARDUINO-Faden
Ja es ollen 2 Motoren mit je 3 V und etwa 200 mA gesteurt werden.
Mehr nicht.
Da werde ich ein Shield kaufen.
danke
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.
Re: Der AVR-/ARDUINO-Faden
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? vergessen:
die pt1000 sollen typ. 1mA sehen, maximal 7mA.
zu erwarten sind so 200° etwa.
PT1000 sind da. Auswertung mit Nano.
Gibt's Einwände gegen das hier? vergessen:
die pt1000 sollen typ. 1mA sehen, maximal 7mA.
Re: Der AVR-/ARDUINO-Faden
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(){};'
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
Re: Der AVR-/ARDUINO-Faden
(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:
Basisformat:
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.
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
- 17.05.2003 | DD.MM.YYYY (national)
Basisformat:
- 20030517 | YYYYMMDD
- 2003-05-17 | YYYY-MM-DD
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.
Re: Der AVR-/ARDUINO-Faden
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/
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/
Re: Der AVR-/ARDUINO-Faden
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
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
- Arndt
- Beiträge: 2589
- Registriert: Fr 28. Jun 2013, 13:42
- Wohnort: einen Schritt über den Abgrund hinaus
Re: Der AVR-/ARDUINO-Faden
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
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.
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
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.
Re: Der AVR-/ARDUINO-Faden
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??
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??
Re: Der AVR-/ARDUINO-Faden
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
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
- Später Gast
- Beiträge: 1705
- Registriert: Di 5. Apr 2016, 22:03
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
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.
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.
-
- Beiträge: 2331
- Registriert: So 11. Aug 2013, 20:25
- Wohnort: Nord-Ost-Westfalen
Re: Der AVR-/ARDUINO-Faden
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.
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.
Re: Der AVR-/ARDUINO-Faden
Kann man machen - und z.B. auf https://access-im-unternehmen.de/Mit_Da ... _arbeiten/ referenzieren: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.
"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!
-
- Beiträge: 2331
- Registriert: So 11. Aug 2013, 20:25
- Wohnort: Nord-Ost-Westfalen
Re: Der AVR-/ARDUINO-Faden
Nunja, Excel halt... Ich habe vor einiger Zeit mit erschrecken feststellen müssen wie unbenutzbar das mittlerweile ist.
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:
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:
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.
- Fritzler
- Beiträge: 12603
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Wenn da jetzt noch _ zwischen die Tokens kommen, dann kann mans auch wirklich lesen.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.
Bei Android sind die Bilder ja so numeriert, da krichste Augenkrebs
- Bastelbruder
- Beiträge: 11566
- Registriert: Mi 14. Aug 2013, 18:28
Re: Der AVR-/ARDUINO-Faden
[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]
Re: Der AVR-/ARDUINO-Faden
was mich beim datum am meisten verwirrt ist das morgen heute gestern ist.
Re: Der AVR-/ARDUINO-Faden
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:
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() {
}
Re: Der AVR-/ARDUINO-Faden
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
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
Re: Der AVR-/ARDUINO-Faden
Das war's!
Heißen Dank!!!
Das Ergebnis wird demnächst bei den fertiggestellten Projekten vorgestellt...
Heißen Dank!!!
Das Ergebnis wird demnächst bei den fertiggestellten Projekten vorgestellt...
Re: Der AVR-/ARDUINO-Faden
das hier ist die ISR von picouart:
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.
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)
);
}
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.
Re: Der AVR-/ARDUINO-Faden
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
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
Re: Der AVR-/ARDUINO-Faden
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...
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...
Re: Der AVR-/ARDUINO-Faden
Braucht du die galvanische Trennung - oder wieso Optokoppler?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
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.
Re: Der AVR-/ARDUINO-Faden
Halloj.o.e hat geschrieben: ↑Di 16. Mär 2021, 16:29Braucht du die galvanische Trennung - oder wieso Optokoppler?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
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.
ja aus dem Inverter kommt ein Optokoppler fähiges Signal.