Oszi für arme

Hallo allerseits!

Solange ich nicht genug Kohle zusammen habe, bis ich mir wieder ein ordentliches Oszi leisten kann, muss ich improvisieren und kleine Brötchen backen.

In diesem Sinne habe ich gestern damit angefangen, mir einen minimalistischen Oszi-Ersatz mit Arduino zu basteln. Der aktuelle Stand ist hier zu sehen. Das Display zeigt die Kurve einer Schwingung mit 100 Hz, wie lange das Aufzeichnen der Kurve gedauert hat (oben links, µs) und bei welchem analogRead()-Wert getriggert wird (oben rechts, „T:xxx“). Mit dem Schalter links kann ich die Trigger-Funktion ein- und ausschalten. Die Knöpfe rechts neben dem Display dienen dazu den Triggerwert zu erhöhen oder zu verringern.
Ganz rechts ist zwar ein kleines Taschen-Oszi zu sehen, aber dessen Buchsen für die Tastköpfe haben einen Wackelkontakt (typisch billiger China-Scheiß, den ich nur noch als Signalgenerator benutze).

Als nächstes wird noch eine BNC-Kupplung gekauft, damit ich statt Messschnüren auch einen richtigen Tastkopf anschließen kann. Und natürlich kommen noch weitere Knöpfe hinzu, damit ich irgendwann auch einen „Cursor“ im Display bewegen kann.

Ich habe im Netz zwar noch ein paar andere Beispiele für derartige Basteleien gefunden, aber weil die mit anderen Displays arbeiten (u. A. auch mit Processing), habe ich mein Gebastel bislang „frei Schnauze“ aufgebaut.

Falls jemand mit Links zu ähnlichen Projekten dienen kann: Immer her damit! Alle Seiten werden zumindest quergelesen. Kommentare und Ideen/Vorschläge sind ebenfalls hochwillkommen!

Schönes Rest-WE!

Gregor

PS: Spaßhalber mal gerechnet: Es werden 121 Pixel der Kurve gezeichnet. Wenn das 19360 µs dauert, sind das 160 µs je Pixel.

Warum postest du dein Bild nicht wie üblich hier im Forum ?
Dann kann man dies wenigstens vernünftig größer ziehen und dich evtl. auf schlechte Lötstellen aufmerksam machen. :wink:

HotSystems:
Warum postest du dein Bild nicht wie üblich hier im Forum ?
Dann kann man dies wenigstens vernünftig größer ziehen und dich evtl. auf schlechte Lötstellen aufmerksam machen. :wink:

Sorry, Gewohnheit. Hier nochmal „richtig“:

Gruß

Gregor

Danke Gregor, so kann man sehr gut alles erkennen. Auch die schlechten Lötstellen.
Nee, ist ein interessantes Projekt.

... ist ein interessantes Projekt.

Auf jeden Fall ist es geil, weil man so zwar ein sehr einfaches aber innerhalb gewisser Grenzen geniales Werkzeug hat, das einem bei weiteren Basteleien hilft. Nuja ... wir machen uns Werkzeuge, um uns noch bessere Werkzeuge machen zu können :slight_smile:

Hast Du Ideen, was man da noch machen könnte? Der Nano hat noch haufenweise freie Pins.

Gruß

Gregor

Also ich habe einen Trio 30MHz 2 Strahl “CS 1570” den ich nicht mehr brauche. Und einen Speichervorsatz von Conrad Elektronik auch nicht mehr der jüngste. Aber beides funktioniert und ist gerne gratis abzugeben.

Abzugeben gegen Abholung. Wenn dann das Geld wieder für einen Speicherosi reicht, dann weg mit dem Teil.

Ich habe mir einen Hantek DSO5072P geholt, da brauche ich den alten Osi natürlich nicht mehr.

Franz

Franz54:
Abzugeben gegen Abholung. Wenn dann das Geld wieder für einen Speicherosi reicht, dann weg mit dem Teil.

In welcher Gegend wohnst Du ungefähr?

82377 Penzberg. Das ist zwischen München und Garmisch.

Franz

kulturbereicherer:
Sind diese OLED Dinger nicht mit HW-SPI Flotter als über I2C?

Falls Du mich fragst: Keine Ahnung.

Ich habe diese I²C-OLED-Displays vor rund anderthalb Jahren kennen gelernt, mir meine eigene Bibliothek dazu geschrieben und fand diese Dinger bislang ausreichend Flott. Den I²C-Code für die Initialisierung habe ich AFAIR vollständig von anderswo genommen, aber Funktionen wie setPixel() oder circle() habe entweder selbst programmiert oder mit Hilfe kompetenter Literatur ausbaldowert. Die letzte größere Erweiterung meiner Bibliothek war das Hinzufügen eines Zeichensatzes mit 7x9 Pixeln.

Das Display war für mich bislang ausreichend schnell. Allerdings wird der I²C-Takt mit meiner Bibliothek auf 400 kHz erhöht. Das ist genug für 25 Bilder/s.

Gruß

Gregor

gregorss:
Das Display war für mich bislang ausreichend schnell. Allerdings wird der I²C-Takt mit meiner Bibliothek auf 400 kHz erhöht. Das ist genug für 25 Bilder/s.

Wofür muss das Display schnell sein?
Die Datenerfassung muss es sein, die Darstellung hat Zeit.

RIN67630:
Wofür muss das Display schnell sein?
Die Datenerfassung muss es sein, die Darstellung hat Zeit.

Klar, für das, was ich jetzt vorhabe, muss das Display nicht schnell sein. Ich habe nur „damals“ den Code für die Initialisierung irgendwo kopiert und dort wird eben das mit den 400 kHz gemacht. Warum ändern, wenn's funktioniert?

Gruß

Gregor

gregorss:
Klar, für das, was ich jetzt vorhabe, muss das Display nicht schnell sein. Ich habe nur „damals“ den Code für die Initialisierung irgendwo kopiert und dort wird eben das mit den 400 kHz gemacht. Warum ändern, wenn's funktioniert?

Möglicherweise, um mehr Resourcen für die Datenerfassung freizuhalten.

RIN67630:
Möglicherweise, um mehr Resourcen für die Datenerfassung freizuhalten.

Ich sehe nicht, wo ein Standard-I²C-Takt von 100 kHz etwas verbessern könnte. Resourcen werden dadurch jedenfalls nicht frei.

Gruß

Gregor

gregorss:
Ich sehe nicht, wo ein Standard-I²C-Takt von 100 kHz etwas verbessern könnte. Resourcen werden dadurch jedenfalls nicht frei.

Klaro werden bei einem schnellerem Takt mehr Prozessorzeit abgezwackt. Das wird nicht hardwaremäßig gemacht.

Wo kann man Dein Code nachlesen?

RIN67630:
Wo kann man Dein Code nachlesen?

Momentan nur bei mir zu Hause. Ich kann meine SSD1306-Bibliothek aber gerne mal posten.

Gruß

Gregor

PS:

Klaro werden bei einem schnellerem Takt mehr Prozessorzeit abgezwackt. Das wird nicht hardwaremäßig gemacht.

Ja, aber wo/wie sollte man die gewonnene Prozessorzeit (wenn denn wirklich welche gewonnen wäre) sinnvoll nutzen?

PPS: Im Datenblatt zum 328P ist in Kap. 22 das „TWI“ (I²C-Interface) beschrieben. Das sieht mir alles sehr nach Hardware aus.

RIN67630:
Klaro werden bei einem schnellerem Takt mehr Prozessorzeit abgezwackt. Das wird nicht hardwaremäßig gemacht.

Die wire-Lib des Arduinos nutzt die Hardware der AtMegas für das I2C Interface. Das eigentliche Senden/Empfangen passiert zwar im Interrupt, die Aufrufe warten aber immer bis der ganze Vorgang abgeschlossen ist. D.h. ein schnellerer Takt beschleunigt die Übertragung und die Aufrufe für die Datenübertragung kehren schneller zurück.

Also heisst das wohl, je schneller der Takt, desto weniger Resourcen/Prozessorzeit benötigt. Dann hat Gregor instinktiv richtig kopiert :wink:

ElEspanol:
Also heisst das wohl, je schneller der Takt, desto weniger Resourcen/Prozessorzeit benötigt.

Ja, für die Arduino Implementierung gilt das so.

Dann hat Gregor instinktiv richtig kopiert :wink:

Puh …

Gruß

Gregor

PS: Da das inzwischen zu einem „richtigen“ Projekt geworden ist, habe ich mal mit einem Schaltplan angefangen (s. Anhang). Wenn jemandem etwas Sinnvolles zu den noch nicht benutzten Pins einfällt … immer her damit!

gOszi.pdf (8.83 KB)

gregorss:
Puh ...

Gruß

Gregor

PS: Da das inzwischen zu einem „richtigen“ Projekt geworden ist, habe ich mal mit einem Schaltplan angefangen (s. Anhang). Wenn jemandem etwas Sinnvolles zu den noch nicht benutzten Pins einfällt ... immer her damit!

Naja das mit dem schnellerer Takt und weniger ressourcen überzeugt mich nicht.
Primär ging es jedoch um die Aktualisierung des Displays mit 25Hz. Schwamm drüber.

Ich würde dir aber empfehlen, die Pins D13 bis D9 für ein SPI interface frei zu lassen.
Schalte lieber deine Kontakte über Widerstände auf Analog(x).
So hast du das SPI interface für was anderes (ggf ein Wireless Transmitter) frei.

Wer weiss, vielleicht magst Du den Signal zum PC schicken und dann würde ich NIEMALS ohne galvanische Trennung arbeiten.