Arduino-Oszilloskop - [Nano Version]

lol :smiley:

so geht es natürlich auch. Ist keine schlechte Idee :wink:
Arbeitest du auch mit Purebasic, sth77?

SBond:
Arbeitest du auch mit Purebasic, sth77?

Manchmal, aber eher auf Einsteiger-Niveau.

oh ok, schade eigentlich.

Ich bin in der Sprache auch noch ein Anfänger und manchmal hängt man an den einfachsten Aufgaben :wink:

Ich müsste es erstmal schaffen ein MacOS X-System unter Windows zu emulieren. Hast du mit so etwas schon irgendwie Erfahrung?

Mit VM Workstation kannst du Mac OS X emulieren.

Auf meinem Windows 7 läuft auch OS X 10.8 Mountain Lion, zwar mit geringer Leistung, aber es läuft.

Zum programmieren reicht es auf jeden Fall, aber ob die fertige Anwendung dann flüssig läuft weiß ich nicht.

Edit: Ich habe probiert dein PureBasic-Programm, welches du schon vor längerer Zeit veröffentlicht hast, zu kompilieren. Es kam aber eine Fehlermeldung. Genau der Fehler welcher mkl0815 schon erwähnt hat.

Grüße,
J3RE

ich werde es mir am Wochenende mal näher anschauen. Die kommenden Tage habe ich leider kaum Zeit dafür.

Das Programm lässt sich auch nicht mit der Demoversion von Purebasic compilieren.
Weis allerdings nicht mit welcher Version J3RE versucht hat das Programm zu compilieren.

Megaionstorm:
Das Programm lässt sich auch nicht mit der Demoversion von Purebasic compilieren.
Weis allerdings nicht mit welcher Version J3RE versucht hat das Programm zu compilieren.

Ich habe es mit der Vollversion versucht.

Grüße,
J3RE

gibt es irgendwo eine Anleitung, wie man Mac auf einem PC emuliert? Ich finde überall solche texte wie: "ohne Lizenz kann man das vergessen" und "die Lizenzen sind an die Hardware gebunden".

Ich tue mich da eventuell etwas schwer, aber ich habe auch keine Ahnung von Apple-Produkten und dessen Betriebssysteme.

zu dem aktuellen Stand des Oszis: Es ist viel zu tun. Komme momentan etwas langsam voran, da ich gerade viele Labortermine habe. Ich will nichts zu viel versprechen, daher sage ich mal, dass das nächste Update erst in 3-4 Wochen kommen wird. Ich bin gerade dabei das Einstellungs-Menü und die Status-Leiste zu programmieren. Wenn das fertig ist, dann kommt das Update.

Gruß
SBond

Wenn du Mac auf dem PC emulierst, weisst du nicht, ob er sich tatsächlich wie ein Mac verhält, insbesondere was hardwarenahe Fragen angeht.
(max. Geschwindigkeit serieller Ports via USB z.B.)

Sollen doch die Apple-Besitzer sich drum kümmern :wink:
Vermutlich ist auch unklar, ob deine purebasic Lizenz dafür gelten würde...

Mach lieber weiter an deinem Nano Oszilloskop.

Meine java-Version hab ich übrigens aufgegeben, nachdem ich gemerkt habe, dass man auch mit c# locker 500kBd statt max. 115200 schafft.

hi..nice work what u have been doing here.

i want to ask something about the way you read the signal. forgive me im really don't understand the theory here.

how you set the arduino ADC to read the signal from the incoming source? did you set the time arduino need to read the signal?
eg: if 50Hz signal. does adc need to set to read every 20ms.?

Hallo SBond,

ich hoffe das Thema interessiert dich noch...

Nachdem ich meine Java Version wegen max. 115200 Bd in die Tonne getreten habe, bin ich auf C# umgestiegen und kann nun bequem 500000 Bd Kommunikation mit dem Arduino fahren, was etwas schneller als die ADC ist.

Bei der Geschwindigkeit der graphischen Darstellung bin ich eigentlich auch zufrieden, da schaffe ich mit lokalen Testdaten max. 100 * 1000 Werte / sec, seit ich alle Werte eines Trends als Polygon zeichne ( und wieder lösche ). Das sollte dann für die < 50.000 Werte/s des Arduino reichen.

Deine >200.000 Werte/s machen mich aber schon neidisch. Wie machen du und dein PureBasic das ???

Falls es interessiert, habe ich den entsprechenden c# Code im Anhang zum Ansehen,
( und wer .net 4.5 installiert hat, kann evtl. auch die test.exe ausprobieren )

Code.zip (1.41 KB)

Exe.zip (5.58 KB)

@dut: sorry, but I was offline last week. I don't know, how I set a time of the ADC. ...but I have changed the ADC-prescaler to get the values 6.5 times faster. The Arduino send the ADC values with his maximum speed over the serial-port (about 20000 to 50000 values per second). Well… I finally enumerate the incoming values (per second) on the computer to calculate the time resolution. I hope I can help you with my poor English. Don’t be shy…. you can ask me anytime. I will help you, if I can.

@michael_x: schön das du auch noch dabei bist. Habe gerade Probleme, da meine Wohnung auf der Elbinsel in Magdeburg gewissermaßen baden gegangen ist. Deine Exe ist interessant. Ich freue mich immer, wenn ich die Möglichkeit habe andere Werke anzuschauen. Ich denke, dass dein Problem aber C# sein wird. Ich habe heute extra für dich 2 Programme geschrieben, einen Benchmark in C und PureBasic. Wenn du einen in C# programmierst, dann kannst du die Leistungen der Programmiersprache besser einschätzen. Auch ich bin erst auf PureBasic umgestiegen, nachdem ich gemerkt habe, dass PureBasic mit ca. 300 FPS „etwas“ schneller ist, als mein altes Programm in AutoIt mit ca. 6-7 FPS. In PureBasic zeichne ich nur einfache Linien… Punkt zu Punkt mit einem Abstand von einen Pixel (horizontal). Im Test konnte ich so bis zu 2 Millionen Linien pro Sekunde zeichnen. Abhängig ist es davon, wie oft ich den Graphen in der GUI aktualisiere. Bei einer Graphbreite von 800 Pixeln und ca. 300 FPS habe ich noch gute 240000 Werte/s. Für diese Zwecke mehr als ausreichend, zumal eine Echtzeitverarbeitung möglich ist ohne Gefahr zu laufen, dass der COM-Puffer überläuft und nur noch verzerrte Signale ankommen (wie es leider bei AutoIt öfters war).

Im Anhang sind die Benchmark-Programme für C, PureBasic und AutoIt (EXE und Quellcodes)

lieben Gruß
SBond

Performance-Test.rar (1.09 MB)

Oh, das Hochwasser ist schlimm dieses Jahr.

Schön, dass du offensichtlich hier wieder Zeit hast und dir nicht alles abgesoffen ist.

Werde mir deine Tests auch mal anschauen. Danke!

Neben DrawPolygon gibt es bei .net (c#) auch noch DrawLines, der Unterschied scheint im wesentlichen zu sein, dass das erste eine geschlossene Figur zeichnet.
Aber vergleichbare Geschwindigkeit. Das Ganze natürlich in einem extra Thread, damit das Programm interaktiv bleibt.

habe heute extra für dich 2 Programme geschrieben, einen Benchmark in C und PureBasic

Sehr schönes Testprogramm, Danke ! Grafik 4 flimmert beeindruckend :wink:

Hier meine Ergebnisse, falls es dich interessiert [Win7 64 bit auf einem 2.17GHz * 2 (intel T7400) ]

Performance-Test: Programmiersprache PureBasic  
------------------------------------------------------------


[ ok ]   Test 1: Ganzzahl von 0 bis 1.000.000.000 hochzählen     [    3261 ms]
[ ok ]   Test 2: Gleitkommazahl von 0 bis 1.000.000 hochzählen   [    4648 ms]
[ ok ]   Test 3: Stringinhalt 100.000.000 mal ändern             [   15725 ms]
[ ok ]   Grafik 1: direkt in die GUI zeichnen         [  38 FPS] [  30714 W/s]
[ ok ]   Grafik 2: in Backbuffer zeichnen             [ 578 FPS] [ 462876 W/s]
[ ok ]   Grafik 3: in Backbuffer zeichnen (skaliert)  [ 287 FPS] [2296945 W/s]
[ ok ]   Grafik 4: in Backbuffer zeichnen (Rauschen)  [ 340 FPS] [ 272487 W/s]
...
by SBond, 09.06.2013

Der Backbuffer wird wohl nur angezeigt, wenn Zeit übrig ist ...
Dafür Flimmerfrei, das ist ja auch was wert, auch wenn man wohl nicht alles sieht und die FPS Werte daher nicht vergleichbar sind :wink:


Beeindruckend, wieviel schneller

char Text[10];
sprintf (Text,"aaaaaaaaa");

gegenüber

Text = "aaaaaaaaa"

in Basic oder wohl auch mit anderen String-Objekten ist.

Dein Tool hatte ich ja auch mal getestet:
1024 DrawLine: 3 FPS
DrawPolygon: 77 FPS

Ich habe ein Intel 2Core Duo mit 2,53 GHz (Laptop)

Schon erstaunlich, dass du mal locker 200 FPS mehr hast als ich xD. In dem Test sieht man schön wie stark der Unterschied ist, wenn man entweder die Werte direkt in das Fenster plottet oder die Werte in den Backbuffer schreibt bis dieser voll ist und den anschließend in der GUI darstellt. Mein Test-Programm ist noch etws ausbaufähig, aber ich habe es gestern nur ''quick and dirty'' geschrieben.

Deinen Code habe ich jetzt noch nicht intensiv analysiert. Zeichnet dein Programm in einem Backbuffer? Wenn ich mir das so ansehe, scheint dein Programm die Werte direkt in die GUI bzw. in ein Grafikobjekt zu zeichnen.

Ja, das DrawLine mit 5 (oder bei dir nur 3 FPS) ist unbefriedigend.

wieviel Programmiererfahrung hast du eigentlich mit C# ?
Ist es schwer zu erlernen?

Edit: nochmal eine zwischenfrage... kennst du dich mit FFT aus? Neben einer Darstellung im Zeitbereich wäre auch eine Darstellung im Frequenzbereich interessant. Bei einem optimierten ADC wäre eine Darstellung bis max. 25 KHz möglich. Fourier-Transformation hatten wir mal im 3. Semester, aber bis heute habe ich es nicht wirklich verstanden ...da es bis jetzt nie eine Rolle für mich gespielt hat. Es gibt zwar viele Quellcodes im Netz, aber ich kann diese noch nicht wirklich nachvollziehen.

wieviel Programmiererfahrung hast du eigentlich mit C# ?
so viel : <--------> :wink:

Hilfe für c# gibt es reichlich. Wenn du ein bisschen c kannst, ist es angenehmer als Basic, finde ich.
Kannst aber auch VB.net nehmen, wenn du keine Semikolons magst und lieber Dim i As Integer als int i; schreibst.

Da, anders als bei Java, keine Unabhängigkeit vom Betriebssystem angestrebt wird, ist man oft näher dran.
Ansonsten das gleiche Konzept (Managed Code, Müllabfuhr, usw., wie du es von Basic gewohnt bist).

Mit Grafik mach ich beruflich nichts. Da sind meine Versuche mit DrawLines() Hobby-Neuland.
Ein Äquivalent zum pureBasic Backbuffer scheint es zu geben, DoubleBuffer, hab ich noch nicht ausprobiert :wink:

Direct2D wäre evtl das richtige, um richtig Performance rauszukitzeln.

c/c++ für Arduino ist schön nach dem Motto "Back to the Roots"
Zum Spass könnte man sich auch in den atmel assembler reinknien.

Fourier-Transformation hatten wir mal im 3. Semester
Wir auch, daher ahne ich, was du mit FFT meinst. Allerdings ist bei mir das 3. Semester vermutlich schon länger her :wink:

C# ist leider nicht so mein Fall, da es soweit ich weiß .Net als Runtime benötigt. Wenn du aber weiter damit arbeiten möchtest, dann solltest du dich in jedem Fall mal in dem Bereich DoubleBuffer einlesen. Das erhöht die FPS-Rate sehr stark. Mit Direct2D hatte ich immer etwas Probleme bei der Verwendung.

....so heute ist erst mal Ruhe angesagt. Mit einer Erkältung kann man wirklich schlecht programmieren :frowning:

Mir schwebte gerade eine Idee im Kopf herum, die - wenn ich sie hier nicht gleich festhalte - vielleicht schnell wieder vergesse. :wink: Und zwar mal wieder geht es um die Mehrkanalfähigkeit. Diese könnte man optional so gestalten, dass Nutzer mit diesem Bedarf die Messwerte eines zweiten Arduino erfassen und darstellen könnten. Programmiertechnisch scheint das aus meiner Sicht keine große Hürde zu sein, und so verringert sich nicht die Geschwindigkeit der Messung im Gegensatz zur Nutzung mit zwei Analogeingängen eines Arduino.