Es gibt 153 Antworten in diesem Thema, welches 12.406 mal aufgerufen wurde. Der letzte Beitrag (
(Versandkosten sind in Euren Rechnungen nicht existent)
Zumindest bei meiner Aufstellung auch Absicht, da man den UNO und das MFS (=Multi-Function Shield) bei eBay ohne zusätzliche Versandkosten bekommt (bzw. auch Angebote mit Versand in Summe dem Preisrahmen entsprechen).
Den Kleinkram kannst du z.B. bei Kessler für 2,95€ Versand bestellen - oder du schlachtest eine alte Kugelmaus aus, da ist alles drin. 
Am besten, man bestellt bei so wenig Anbietern wie möglich. Versandkosten sind bei den geringen Kosten von Elektronik oft ein relevanter Faktor.
Ich hatte ehrlich gesagt 3x Versand.
Arduino plus Shield.
Widerstände plus Photodioden.
Laser.
Eventuell gleich an Batteriehalterung / Akkuhalterung und An/Aus Schalter denken.
Akkuhalterungen gibt es mit im Arduino Shops. Auch gleich mit Schalter integriert.
In einem Verein, ... kann man Sammelbestellungen machen und so die Kosten noch recht stark drücken.
Gruß Play
So, das Rohr ist nun da. 
3,5cm Durchmesser. Mal schauen, ob's das tut.
(Versandkosten sind in Euren Rechnungen nicht existent)
meine teilekosten bezogen sich tatsächlich auf preise inklusive porto vom pingpong versand (oder halt portofrei gelistet)
man kommt natürlich immer besser weg wenn man die gleich im 10er paket oder größer kauft
laut Datenblatt hat der auch nur einen ADC.
aber 2 offene GPIOs mit denen kann man eh mehr anfangen. n adc braucht zu lange zum auslesen, da wird das mit hohen geschwindigkeiten nix.
interrupts sind da eigendlich angesagt, aber selbst mit polling ist man da schon besser dran
brauchst du immer noch ein zusätzliches WLAN-fähiges Gerät wie Smartphone oder Notebook
als hätte das heutzutage nicht eh jeder in der tasche....
Du brauchst ein FTDI-Interface,
das gehört ja nu nicht wirklich zum stückpreis...
wenn man das alleine nachbastelt vielleicht, aber wer sowas tut hat son ding eh in der grabbelkiste. ein arduino kann dafür übrigens auch herhalten
aber 2 offene GPIOs mit denen kann man eh mehr anfangen.
Der Punkt meiner Aussage war, dass du dadurch noch ein paar Bauteile mehr brauchst und da schlicht nix mit "5€" ist.
das gehört ja nu nicht wirklich zum stückpreis...
Doch, tut es. Denn im Gegensatz zu einem normalen USB-Kabel hat keiner, der das dann nachbauen will, sowas in der Schublade.
btw ich empfehle IR lichtschranken. die sind streulicht unempfindlicher.
So wie ich die Röhre gerade baue, wird da nicht viel Streulicht reinkommen (5cm innenliegend vom Rand, matt-schwarze Röhre, Sensor hinter einem Loch). Aber wer das später nachbaut, kann natürlich auch IR oder Laser nehmen. Jeder, wie er mag.
Kosten könnte man sparen, wenn man eine Kleinserie zum Selbstkostenpreis für Leute hier in der Intressengemeinschaft bereitstellen würde.
Nachdem ich mir eben beim Löten übelst den Zeigefinger verbrannt habe, hab ich jetzt mal noch etwas an der Bedienung optimiert. Das Geschoss-Gewicht hat jetzt dynamische Schritte, je nach Wert. Bis 2,5 Gramm geht es in 0,01-Schritten, bis 10 Gramm in 0,1-Schritten und danach in 1er-Schritten. So kann man auch "schnell" schwerere Geschosse einstellen und bei denen ist die Angabe dann meist eh nur noch auf 1 Gramm genau angegeben.
aber 2 offene GPIOs mit denen kann man eh mehr anfangen. n adc braucht zu lange zum auslesen, da wird das mit hohen geschwindigkeiten nix.
interrupts sind da eigendlich angesagt, aber selbst mit polling ist man da schon besser dran
Der übliche Weg wäre ein Input Capture Interrupt von einem Timer. Wichtig ist, dass das zwei unabhängig Kanäle vom gleichen Timer sind, dann kann man direkt die Capture Werte aus den Registern voneinander subtrahieren.
Einen Interrupt braucht man dann nämlich auch nicht mehr, die Capture Werte laufen ja nicht weg. Spart die nervige Synchronisierung die von Embedded Anfängern eh meistens buggy gelöst wird. Einfach Pollen bis beide Capture Kanäle ihr Capture flag gesetzt haben und gut.
Interrupts braucht es nur wenn man mehrere Events bekommt und filtern will/muss.
GPIO pollen ist Käse, da hat man unnötig undefinierten Jitter drin. Vor allem wenn die MCU nur unwesentlich schneller als der Timer läuft und nur mit 8 Bit rechnen kann.
Kleinserie zum Selbstkostenpreis
Teile und Anleitung. (auch gerne als Adventskalender 
)
Neben der Reinigung einer Bildröhre habe ich auch mal löten gelernt.
MCU nur unwesentlich schneller als der Timer läuft und nur mit 8 Bit rechnen kann.
der esp8266 ist n 32bit prozessor und läuft für gewöhnlich mit 80MHz
das ist um einiges schneller als ein arduino uno mit seinem 8 bit atmel
klar ist pollen nicht ideal, aber das ding soll ja nur zwei pins überwachen und ab und an mal ne zahl ausrechnen. da geht polling gerade noch so.
das ist um einiges schneller als ein arduino uno mit seinem 8 bit atmel
Da würde ich jetzt mal widersprechen. Weder 32-bit noch die 80 MHz machen das Teil automatisch "um einiges" schneller. Der ESP8266 basiert auf einem DSP-Design mit nur 80 Opcodes. Der braucht für vieles unnötig komplexe Befehlsketten, weil oft native Befehle fehlen. Ist halt keine General Purpose CPU.
Der AVR des Arduino UNO z.b. hingegen wurde speziell auf die C-Sprache optimiert, d.h. es wurden Opcodes in die Architektur aufgenommen, die in C oft vorkommende Situationen abdecken. Dadurch ist die Code-Ausführung enorm schnell. Der UNO macht 16 MIPS, was 1:1 dem Takt entspricht.
Wichtig ist das freilich nicht. Selbst der UNO ist weitaus schneller, als für einen Chrony nötig. Rein rechnerisch kann ich bei 30cm Sensor-Abstand locker bis 2.999 m/s messen. Hat die Ausführzeit des Main-Loops bestätigt, die unter 1 ms liegt.
das ist um einiges schneller als ein arduino uno mit seinem 8 bit atmel
Da würde ich jetzt mal widersprechen. Weder 32-bit noch die 80 MHz machen das Teil automatisch "um einiges" schneller. Der ESP8266 basiert auf einem DSP-Design mit nur 80 Opcodes. Der braucht für vieles unnötig komplexe Befehlsketten, weil oft native Befehle fehlen. Ist halt keine General Purpose CPU.
Der AVR des Arduino UNO z.b. hingegen wurde speziell auf die C-Sprache optimiert, d.h. es wurden Opcodes in die Architektur aufgenommen, die in C oft vorkommende Situationen abdecken. Dadurch ist die Code-Ausführung enorm schnell. Der UNO macht 16 MIPS, was 1:1 dem Takt entspricht.
Wichtig ist das freilich nicht. Selbst der UNO ist weitaus schneller, als für einen Chrony nötig. Rein rechnerisch kann ich bei 30cm Sensor-Abstand locker bis 2.999 m/s messen. Hat die Ausführzeit des Main-Loops bestätigt, die unter 1 ms liegt.
Besser als per Capture Interrupt wird es nicht. Die kleinste Auflösung bei 1MHz Timertakt ist dann 1us was bei 30cm "etwas" mehr als 3000m/s wäre
Die Ausführungszeit der Mainloop ist relativ irrelevant, da zwischen Pin erkannt und Timer gelesen eine zwar fixe, aber undefinierte Zeit liegt. Die auch nicht zwingend für beide Kanäle gleich ist.
Was die Architektur angeht ist ein 32 bitter der praktisch alles aus allzweck Registern adressieren kann inklusive indiziertem Zugriff jedem 8 bitter überlegen. zwar hat der AVR mehr allzweck Register, braucht aber für vieles mehrere und muss mit Übertrag rechnen.
Da ist ein Cortex oder ESP bei gleichem Takt immer fixer.
Kurzum, der Capture Input ist das Mittel der Wahl. Dann reicht auch 8 MHz MCU Clock und 1MHz Timertakt.
Was die Architektur angeht ist ein 32 bitter der praktisch alles aus allzweck Registern adressieren kann inklusive indiziertem Zugriff jedem 8 bitter überlegen.
Eben das ist falsch. Das ist ein Märchen genau wie mehr MHz = schneller.
Vergleiche mal einen Z80 (8-bit) mit einem 68000 (16/32-bit). Bei gleichem Takt ist der Z80 im MIPS-Benchmark doppelt so schnell. 32-bit hat Vorteile, wenn du mit großen Zahlen rechnest oder "viel" Speicher (>64kb) adressieren willst. Machst du das nicht, spielt es keine Rolle für die Geschwindigkeit.
Das geht aber schon ins Off Topic. scarvig kann ja gerne einen eigenen Thread erstellen, wenn er die Idee mit dem ESP8266 ernsthaft umsetzen will.
Zum 68000der.
Der hat wesentlich mehr Register und alle sind nicht fest definiert sondern gleichwertig als Alu. Das macht Ihn verdammt schnell. Es geht nicht immer nur um Bitbreite und MHz.
Der Z80 ist von den Registern begrenzter. Genau wie ein 6502 oder 6510. Der 68000 ist wesentlich weiter entwickelt.
Aber nicht quatschen. Macht. Wie wäre es mit einer Challenge. Jeder baut einen Chrony und dann vergleichen wir.
Gruß Play
Vergleiche mal einen Z80 (8-bit) mit einem 68000 (16/32-bit). Bei gleichem Takt ist der Z80 im MIPS-Benchmark doppelt so schnell. 32-bit hat Vorteile, wenn du mit großen Zahlen rechnest oder "viel" Speicher (>64kb) adressieren willst. Machst du das nicht, spielt es keine Rolle für die Geschwindigkeit.
Achja, der U880
Klar kann man per Assembler handoptimierung, aber das macht im Jahr 2022 keiner mehr. Schon beim Zugriff auf Adressen die mehr als 256 Bytes auseinander liegen (oder oberhalb der ersten 255 Bytes) wird es bei den meisten 8 Bittern eng.
In der Praxis ist der Maßstab das man aus dem GCC performanten Code bekommt. Idealerweise mit einem C++ Compiler (die dynamischen Sachen braucht man ja nicht zu benutzen), um ein paar nette Sachen wie OOP, Typensicherheit und Boundary checks benutzen zu können. Und spätestens da stinkt jeder 8 Bitter ab.
Nochmal etwas am geplanten Aufbau geändert: statt die beiden LEDs einfach an 5V zu hängen, schließe ich die an jeweils einen PWM-Pin an. Dann kann ich die nicht nur per Software ein- und ausschalten, sondern auch automatisch regeln, wenn z.B. der Sensor zu nahe am Sättigungswert ist. Der Chrony kann sich dann beim Einschalten quasi selbst kalibrieren, um LEDs und Sensoren aufeinander abzustimmen. Vermutlich sinnfrei, aber schaden kann's auch nicht.
Und Ausgabe der Konfiguration und Messwerte über den seriellen Port baue ich auch noch ein. Dann kann man das Teil per USB anschließen und eine komplette Mess-Session loggen.
Cooler Thread 
Das alles erinnert mich an längst vergangene Zeiten, als wir Rechenschaltungen aus Logikbausteinen zusammenklöppeln mussten.
