Und es gibt keine spezielle AVR-Projekte. Es sind nur AVR-Projekte.
Vergiss dein spezielles.

_________________
mfg Jornbyte

Es handelt sich bei dem Tipp nicht um eine Rechtsverbindliche Auskunft und
wer Tippfehler findet, kann sie behalten.

Hallo,

Don Comi: ja, ich hatte schon mal wegen allgemeiner Fragen zu MC´s gepostet, aber noch nicht speziell zu den Programmiersprachen. Ich habe lediglich über diese Sprachen in Erfahrung bringen können, dass manche von ihnen schneller und verständlicher bzw. leichter sind, als andere, dafür mit den "leichten" aber nicht alles machbar sei. Um eine LED zum blinken zu bekommen, reicht auch der Arduino. Mein Vorhaben ist vermutlich aber doch nicht ganz einfach, wie mir auch in vorangegangenen Postings mehrfach mitgeteilt wurde. Deshalb habe ich vermutet, dass evt. die "leichten" Sprachen (z.B. Bascom?) dafür nicht so gut geeignet sind.
Deiner Antwort entnehme ich, dass mit allen Sprachen alles machbar ist (?). Auch mein spezielles Projekt.

Danke für die Antworten.

Andi

Die begrenzung des machbaren liegt in der Codegrösse und der Ausführungsgeschwindigkeit.

Für deine "spezielle" anwendung sollte jedoch noch alles einigermassen geeignet sein.

Tu dir selbst den Gefallen und lern C
Ich selbst hab aus faulheit mit Basic angefangen und nun kleb ich an dieser Plattformabhängigen langsamen Sprache und komm nicht mehr davon los.

Wie gesagt, grundsätzlich gilt: die Lösung eines (informationstechnischen) Problems sollte nicht an eine bestimmte Programmiersprache gebunden sein (nicht mal an eine Architektur).

Also: die Problemlösung sollte generell erfolgen, z.B. in Form einer mathematischen Vorschrift, eines Flussdiagramms, eines Zustandsdiagramm oder in Pseudocode.

Wenn das Problem soweit gelöst ist, kann man es implementieren, und zwar auf jeden Fall in jeder Sprache!
(Die eine oder andere Sprache ist aufgrund ihrer Struktur und Arbeitsweise mal mehr, mal weniger geeignet. Z.B. würde kein Mensch einen kompletten Webserver in Assembler schreiben, auch wenn dies natürlich ginge (theoretisch...))

Soweit Theorie, praktisch muss man noch andere Dinge miteinbeziehen.


Ich empfehle grundsätzlich das Erlernen der Sprache C für AVRs. Wenns später mal ein wenig zeitkritischer wird, lässt sich eigener Assemblercode problemlos hinzulinken.
C ist theoretisch zumindest plattformunabhängig und du kannst auch „Trockenübungen” am PC ohne µC machen.

Gedanken musst du dir natürlich auch über die Hardware machen; z.B. wie schnell die Daten ankommen bzw. wie groß der Abstand zwischen zwei Symbolen (ASCII-Zeichen) minimal ist, also welche Baudrate der Sender benutzt.
Da muss der µC auf jeden Fall mithalten.


_________________

Zitat :

C ist theoretisch zumindest plattformunabhängig und du kannst auch „Trockenübungen” am PC ohne µC machen.

Im MPLAB-Simulator kann ich auch Assembler-Trockenübungen für den PIC ganz ohne PIC am PC machen
Ansonsten ist es bestimmt auch nicht verkehrt, sich als Einsteiger ein paar Assembler-Tutorials querzulesen. Nicht unbedingt, um damit auch zu programmieren, sondern um besser zu verstehen, wie so ein µC überhaupt arbeitet (Register, Datenwörter etc.).


Gruß, Bartho

"Gedanken musst du dir natürlich auch über die Hardware machen; z.B. wie schnell die Daten ankommen bzw. wie groß der Abstand zwischen zwei Symbolen (ASCII-Zeichen) minimal ist, also welche Baudrate der Sender benutzt.
Da muss der µC auf jeden Fall mithalten."


Ja, Nachdenken tue ich auch darüber schon eine Weile Wie bzw. mit welchen Hilfsmitteln bekomme ich da die Ergebnisse? Ich habe lediglich ein Programm bisher, welches mit die SysEx-Daten, die "unterwegs" sind, ausliest und anzeigt. WIe kann ich das messen?

Andi

Zur Hardware:

Die Daten kommen mit 31250bps, also 31,25kBaud.
Das ist recht langsam und ein mit einigen MHz getakteter AVR schafft das problemlos.
(Es gibt eine Formel zur Berechnung des Baudratenregister-Inhalts).
Weiterhin musst du natürlich die MIDI-Daten elektrisch so verändern, dass du sie mit der UART verbinden kannst. MIDI definiert eine Stromschnittstelle, die UART am µC erwartet Spannungspegel. Per google lassen sich kleine Schaltungen dazu finden.


Im MIDI-Protokoll wird genau beschrieben, wie sysEx-Daten eingespeißt werden können.
D.h., du musst zuerst einmal auf die Sequenz warten, die diesen Teil einleitet.
Dann extrahierst du den Datenblock und wertest ihn aus.
Danach wartest du wieder auf die Sequenz im Datenstrom, die sysEx-Daten einleitet.

Es gibt mehrere Möglichkeiten, wie die Auswertung erfolgt:
· Byteweise: nach jedem neuen Zeichen schaust du schon, ob es interessante Daten sind, oder ob man sie ignorieren kann. Das System braucht ein Gedächtnis, um mehrere Zustände zu speichern,
· Blockweise: du wartest auf die Startsequenz für die systemexklusiven Meldungen. Dann beginnst du, alle folgenden Bytes bis zum $F7 in einen Puffer zu schreiben.
Wurde das Ende der Sequenz erkannt, kannst du mit den mem*-Funktionen aus der Standard-Library (memncpy^* in diesem Fall bzw. memcpy) diesen Block mit anderen Daten vergleichen.

Gibt auch noch andere Möglichkeiten und kompliziert ist das Ganze eigentlich nicht.

^* memncpy ist besser, da nur soviele Bytes verglichen werden, wie angegeben.
Weiterhin gilt bei Puffern immer, dass Puffer auch irgendwann voll sein können, wenn z.B. die SysEx-Meldungen zu lang sind. Man muss also dafür sorgen, dass der Puffer nicht überläuft und andere Bereich im SRAM überschreibt, einfachere µCs tun das einfach so, ohne dass ein Betriebssystem das Programm als Prozess überwacht (und selbst dann passiert es ).

_________________

Zitat :

Ich habe lediglich ein Programm bisher, welches mit die SysEx-Daten, die "unterwegs" sind, ausliest und anzeigt. WIe kann ich das messen?

Verstehe ich nicht.


Gruß, Bartho

Naja, er wird ein Sniffer haben, der die MIDI-Daten irgendwo abgreift und ein wenig aufbereitet darstellt.

Ich verstehe den zweiten Teil des Satzes als Fragestellung, wie man elektrisch an die Daten herankommt und dazu sagte ich ja, dass er eine kleine Schaltung benötigt, die das Signal anzapft und als Spannungspegel ausgibt. Der Ausgang dieser Schaltung kann dann direkt mit dem UART-Eingang des µCs verbunden werden.

Aber stimmt, ich empfinde den Satz auch als unverständlich.

Offtopic :

Zitat : m MPLAB-Simulator kann ich auch Assembler-Trockenübungen für den PIC ganz ohne PIC am PC machen Jo, das kann ich auch Im AVR-Studio ist das sogar grafisch wesentlich ansprechender als in einem Shell-Simulator.

_________________

Hallo,

danke für die Antworten, besonders Don Comi: sehr ausführlich und für mich sehr hilfreich. Danke . Und: ja, der zweite Teil des Satzes war als Fragestellung gemeint, worauf sich ja dann Deine Antwort auch bezog.

Nun denn: frisch ans Werk


Andi